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Kijutni csak akkor 
tudunk, ha a bálvány 

LElhz AE IGJAS TT EZzT Ta 

a térképet. 

Na ez az RSA. 

Aki nem tudja..." 
(MUTAT 


19. oldal 
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Az infopen.hu webmagazin és az infoBbYTE közös rovata, 
kifejezetten IT vezetők számára. A rovat egy aktív CIO-val 


készült átfogó interjúval indul, amelyet stratégiai jellegű 
technológiai áttekintések, szakcikkek követnek. A rovat 
hangsúlyos részei a vállalati IT megoldásokat bemutató 
A távközlési piac liberalizálása és a mobiltelefóniában várható esettanulmányok, de interjúk, konferenciatudósítások 
generációváltás érdekegyeztetési törekvéseiről tudósít eza rovat. —— formájában a piac meghatározó megoldásszállító cégeinek üzleti 
és termékstratégiájának bemutatása is helyet kap. 


A hónap vezető cikke új technológiákról, megoldásokról. 
Tapasztalatok szerint három-négy évente változtatunk mi, 
informatikusok állást, szakmát vagy szakirányt, és ez a szám a 
Külfödi hírek, kitekintés. jövő évtizedekben valószínűleg csökkenni fog. 


Az Informatikai Kormánybiztosság 2001— 2002-ben E rovatunkban olvasóink nevében és helyett Novell szakértőket 





összesen 36 különféle programot koordinál. Az információs kérdez a szerző. 
társadalom kiépítésének lépcsőfokai ezek. 


A NetAcademia-féle mélyvíz-tanfolyamokra iratkozhatnak be 
Az Inforum célja, hogy párbeszédet folytasson a szakma és a azon olvasóink, akik Dr. Watson nyomában járnak. 
kormányzat között. Aktív szerepet vállalt a szerzői jogi, az 
egységes hírközlési és az elektronikus kereskedelmi törvény 
megalkotásában. Hardver- és szoftvertesztek röviden, velősen. 


Ebben a rovatban nem elsősorban a technológiára, hanem a Sokakat érdeklő CPU-újdonságok mélységei 
megvalósult projektekre, az EU-kompatibilitás kérdéskörére, a fejlesztéshez közel álló szakértők tollából. 
pályázatokra koncentrálunk. 


Kérjen mintapéldányt: minta€infobyte.hu 
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Júzerstílusban 

Érdekes világ ez! Először kínainak tűnik az 
egész. Szakemberek beszélgetnek egymással, 
a júzer meg ül bambán és hevesen csattog- 
tatja a klaviatúrát. Heves vitatkozás bonta- 
kozik ki a háttérben, a júzer pedig megpróbál kihámozni va- 
lamit a hallottakból - ,ők tényleg más nyelvet beszélnek"! 
Júzerünk arra hivatkozik, hogy még csak most vágott bele 
a számítástechnika új nyelvének megtanulásába és a szük- 
séges készségek elsajátításába, lesz még elég ideje, hogy 
megértse azt, felmentést ad tehát magának. Különben is, 
nem lehet mindent érteni a világ dolgaiból! 

Felmentés megvan, már csak júzerként kell jól helytállnia 
főszereplőnknek. Megtanulja miért kell folyamatosan men- 
téseket végezni, miután elveszíti 10 oldalas gépelt doku- 
mentumát sőt azt is, hogy az egeret valójában nem a kép- 
ernyőn kell mozgatni, hogy be tudja célozni a megfelelő 
ikont :-) Idővel össze tud rakni egy gépet, már ami a pe- 
rifériák csatlakoztatását jelenti; ebben a folyamatban - per- 
sze a gyengébbek kedvéért - a segítségére vannak a doboz 
hátulján lévő csatlakozók színkódjai is. 

Számtalan dolgot meg tud már oldani egyedül. Már nem 
futkorászik és nyaggatja a rendszergazdákat, ha esetleg 
nem megy a nyomtatás - büszkén keresi meg Word doku- 
mentumának nyomtatási beállításait vagy a nyomtató beál- 
lításait a start menüből. Költőien: 





Change drum? 
Ismerem! 
Toner low? 
Cserélem! 


De akkor sem zavarja a rendszergazdát, ha esetleg semmi 
sem úgy működik a gépen, mint mondjuk tegnap este - tisz- 
tában van vele, hogy egy restart mindent megold! Vagy ha 
nem, hát a regedt32.exe. Ha gondja van, csak besétál a 
HKLM/Software/MSLicensing alá és 


Törli, amit törölni kell, 
Tudja, mi fán terem 

a dúr akkord, 

a ctrl--alt--del. 
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Júzerstílusban 


A ,How are you?" - kezdetű levelet megtanulja csatolt do- 
kumentumával együtt shift--del-lel megsemmisíteni. 
Feliratkozik a NetAcademia levlistáira - mondjuk csak az OFF 
jöhet szóba - de a nyelvezettel még így is gondok adódhatnak 
(de mi az a: rulez, warez, TOFL, szvsz meg a többiek? Hhűű!) 
Néha megkapja a júzeres vicceket! Olykor érti is a poén tár- 
gyát, amelyiket meg nem - hát a belső szobából kiáramló 
jókedv azért készteti mosolygásra, mert tudja, hogy ez bi- 
Zzony róla: a júzerről, és a tudatlanságáról szól. Hadd neves- 
senek! Én is röhögök a szőke nős vicceken ! :-) 

A számítástechnika világában, júzerként inkább a ,perifé- 
rián" csücsülünk, de örömmel vesszük a kis magyarázato- 
kat, amivel munkánk könnyebbé tehető, amivel valamivel 
többet megérthetünk a számítástechnikai csiki-csukikból. 
Persze ehhez júzerként is folyamatos tanulásra van szükség, 
illetve képzett szakemberekre, akik megoldják a , gondjain- 
kat" helyettünk és értünk. 


tech.net 

A tech.net idén ünnepelte 1 éves születésnapját, amit gyerek- 
pezsgővel és tortával ünnepeltünk. Rengeteget köszönhetünk 
olvasóinknak, akik vették a fáradságot, hogy jelezzék nekünk 
pozitív és negatív észrevételeiket és buzdítsanak bennünket! 
Tartsák meg jó szokásukat, mert minden észrevétel számít. 

E számunkban teret engedtünk fantáziánknak és jó hangula- 
tunknak is: az ünnepi készülődés és a szilveszteri jókedv jegyé- 
ben az utolsó négy oldalt komolytalanságoknak szenteljük. 
Üzenetem végére érve, júzerként és egy emberként (a júzer 
is ember!) kívánok mindenkinek még sok türelmet hozzánk: 
júzerekhez, sok viccet rólunk, és kitartó munkát. 


Szerkesztőségünk nevében kívánok kellemes karácsonyi ün- 
nepeket, boldog új évet és zökkenőmentes áttérést a 2002. 
évre. Idén nincs bug? Tavaly mintha lett volna valami. Vagy 
tavalyelőtt...? 


Kovács Barbara 
barbi onetacademia.net 





tech.net! 


Farkasokkal 


táncoló (II. rész) 
Cluster a gyakorlatban 


Miután elsajátítottuk az alapfogalmakat és összeállítottunk 
egy Achilles sarkoktól mentes konfigurációt, megkezdhetjük 
az előkészületeket a telepítésre, majd el is végezhetjük azt. 


Előkészületek 

EL kell döntenünk, hogy hány erőforráscsoportot, illetve vir- 
tuális szervert szeretnénk létrehozni. A számuk idővel per- 
sze változhat, de most azért van erre mégis szükség, mert 
minden egyes csoporthoz külön lemezt kell rendelni. A le- 
mez (physical disk) egy erőforrás, az pedig egyszerre csak 
egy csoporthoz tartozhat. A cluster bizonyára egy lemezal- 
rendszert ér el, amely egy vagy több redundáns lemeztöm- 
böt (disk array) tartalmaz. Ezek a lemeztömbök valamilyen 
hardveres redundanciával kell, hogy rendelkezzenek attól 
függően, hogy milyen alkalmazás használja majd őket. A le- 
meztömbök fölött a diszkalrendszer számára logikai lemeze- 
ket lehet definiálni. Ezeket a logikai lemezeket az operációs 
rendszer fizikai lemezként fogja felismerni. Az alábbi ábra 
egy lehetséges lemeztömbfelosztást mutat be, a következő 
pedig azt, miként látja ugyanezt a Windows 2000. 
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2 ... és a Windows 2000 szerint. 
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Valamennyi általam ismert lemezvezérlő képes arra, hogy mű- 
ködés közben új lemezeket fogadjon a tömbbe, s azokon újabb 
logikai (a Windows számára fizikai) lemezeket hozzon létre. 
Jóval kényesebb kérdés a már meglévő logikai lemezek meg- 
növelése. Ez sem lehetetlen, de általában már csak borsos árú 
kiegészítőszoftverekkel lehet elvégezni. Ennek hiányában nem 
kis erőfeszítés lesz a megtelt lemezt nagyobbra cserélni. 
Fontos kiegészítés, hogy a definiált diszkek éppúgy viselked- 
nek, mintha tényleges lemezek volnának. Ez többek közt azt 
is jelenti, hogy rajtuk (elsődleges) partíciókat lehet létrehoz- 
ni. Az erőforráscsoportok azonban nem ismernek ,partíció" 
erőforrást, tehát ha egy lemezen több partíció van, akkor 
mindegyik azonos csoportba fog kerülni. A lemezeket NTFS 
formátumra kell formázni, és tilos átkonvertálni dinamikussá. 
Mindezen ismeretek alapján azt javaslom, hogy a cluster 
bőven tartalmazzon szabad merevlemezterületet. Egyrészt 
fölös terület szükséges a hardveres redundancia biztosítá- 
sára. Másrészt minden egyes definiált lemez esetén lehető- 
vé kell tenni az adatok számára a , szaporodást és sokaso- 
dást". Vagyis minél több lemezt definiálunk, annál több 
szabad hellyel kell számolni, hiszen a szabad hely felapró- 
zódik közöttük. Például: ha a DHCP és a WINS szolgáltatást 
külön virtuális gépen definiáljuk, akkor külön diszket kell 
hozzárendelni az erőforráscsoportokhoz, tehát mindkét 
szolgáltatás jövőbeli tárkapacitásigényét külön kell megbe- 
csülnünk. Ha egy csoportban helyezzük el őket, akkor lehet- 
séges, hogy a számolt szabad kapacitás kisebb lesz, ezáltal 
a közös diszk sem lesz akkora, mint az első esetben. 

Azt kell látni, hogy két, egymásnak ellentmondó igényt kell 
kielégíteni. Minél több virtuális csoportot kell létrehozni ah- 
hoz, hogy a szolgáltatások egymástól függetlenek legyenek, 
ugyanakkor ez jóval több erőforrást igényel (memóriát és főleg 
tárolóhelyet) , ez viszont erőforrás-, végső soron pedig pénzpa- 
zarláshoz vezet. Ha a pénztárca és a konfiguráció igényeit 
össze akarjuk hangolni, érdemes bizonyos szolgáltatásokat 
összevonni, és csak néhány, , nagyobb" virtuális szervert létre- 
hozni. Azt javaslom, hogy a virtuális szerverekhez az egyes 
szolgáltatásokat a karakterisztikájuk alapján soroljuk be. Na- 
gyon leegyszerűsítve kétféle szerverszolgáltatás létezik: a fájl- 
és az alkalmazásszolgáltatás. Az előbbi intenzíven veszi igény- 
be a merevlemezeket, I/O csatornákat és hálózati kártyákat, 
míg az utóbbi rengeteg memóriát, és magas órajelű, gyorsabb 
processzorokat kíván. A Windows 2000-t - sőt már a korábbi 
NT verziókat is - egyszerűen lehet hangolni ezekre a felada- 
tokra. Ha az állomást inkább fájlszolgáltatás jellegű feladatok- 
ra optimalizáltuk - ilyen a fájlmegosztás, a nyomtatás, az IIS 
- érdemes odaköltöztetni azokat a virtuális gépeket, amelyek 
erőforrásai hasonló feladatokat látnak el. Fordítva hasonló- 
képp: az alkalmazásjellegű erőforrásokat tartalmazó csoporto- 
kat az alkalmazáskiszolgálásra hangolt node fogadja be. 
Ennyi tudás birtokában már papírra lehet vetni a virtuális 
szerverek tervét. Szükség van egy névre (15 karakternél nem 
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hosszabb, a NetBIOS nevekre vonatkozó korlátok figyelembe vé- 
telével kell megalkotni), IP címre (kizárólag statikus cím le- 
het) , valamint a szükséges szolgáltatásokra és merevlemez te- 
rületekre. Az egyes merevlemezeket mindkét állomáson szigo- 
rúan azonos betűjellel kell ellátni. Egyes dokumentációk azt 
javasolják, hogy abc sorrendben visszafelé érdemes betűjele- 
ket adni, de ez nem kötelező. Jómagam előnyben részesítem 
a funkció szerinti jeleket, pl. 0-guorum, E-Exchange stb. 
Utolsó lépésként az előkészítés során egy megfelelő jogo- 
sultságokkal rendelkező fiókot kell létrehozni, ennek a kon- 
textusa alatt működik majd mindkét állomáson a cluster- 
szolgáltatás. Több forrás is egyértelműen állítja, hogy a 
fióknak adminisztrátori fióknak kell lennie, ez azonban nem 
teljesen pontos. Személy szerint nagyon nem szeretem, ha 
ritkán változó jelszóval rendelkező fiókok (és a szervizek 
fiókjai általában ilyenek) indokolatlanul nagy hatalomhoz 
jutnak. Ha valaki el szeretné kerülni, hogy tartományi rend- 
szergazdává léptesse elő a clusterfiókot, akkor a következő 
jogok megadásával elkerülheti ezt: 

I Lock pages in memory 

Log on as a service 

Act as part of the operating system 

Back up files and directories 

Increase guotas 

Increase scheduling priority 

Load and unload device drivers 

Restore files and directories 

Az első három jogosultsággal alapértelmezetten a tartomá- 
nyi rendszergazdák sem rendelkeznek. A jogokat vagy tar- 
tományi vagy OU (organization unit) szinten, de akár az ál- 
lomásokon is meg lehet adni. Ez utóbbi a legbiztonságo- 
sabb, habár sok munkával jár. Az OU szint egy elfogadható 
kompromisszum, feltéve, hogy az 0U direkt a clusterek ad- 
minisztrálásának elkülönítésére jött létre. 

A fiókot a Windows NT Account tartományban vagy az 
Active Directory-ban kell létre hozni, s ez logikus is, hiszen 
mindkét állomáson elérhetőnek kell lennie ennek a fióknak 
- a tartományi felhasználók ilyenek. A fiókot egyébiránt a 
szervizaccountokhoz hasonlóan érdemes kezelni (a jelszó 
nem jár le; a felhasználó nem változtathatja meg a jelszót; 
hosszú, komplex és erős jelszót kell megadni stb.) 

Az állomásoknak kötelezően tartományi tagoknak kell lenniük, 
de ezen belül a szerepük nem korlátozott, lehetnek tagkiszol- 
gálók és tartományvezérlők is. A szerepekről a későbbiekben 
még részletesen beszélünk. Most annyit érdemes tudni, hogy 
mindkét állomásnak azonos szerepet kell adni: vagy mind a 
kettő legyen tagkiszolgáló, vagy tartományvezérlő. A szerepe- 
ket a clusterszolgáltatás telepítése előtt kell beállítani. 


ké: 
Va 
hú) 
Tv 
nm 


kés) 
Más) 


A telepítés 

Elég sokat tudunk már, fogjunk bele a telepítésbe. Feltételez- 
zük, hogy mindkét állomáson működik a tartomány tagjaként a 
Windows 2000 Advanced Server. Vezérlőpult Programok hoz- 
záadása Windows komponens telepítés Cluster service. 

Az első párbeszédpanel arra hívja fel a figyelmünket, hogy 
a konfigurációnak, amelyre a fürtszolgáltatást telepítjük, 
szerepelnie kell a Microsoft által kiadott hardverkompatibi- 
litási listának azon szűkített változatán, amely a kiszolgá- 
lófürtökre vonatkozik. Ez éles rendszer esetén evidens, a le- 
hetséges szállítókat meg kell kérni, hogy igazolják eszkö- 


A MICROSOFT MAGYARORSZÁG SZAKMAI MAGAZINJA 
2001. AZ: 


(II. RÉSZ) CLUSTER A GYAKORLATBAN 

zeik jelenlétét a listán, de ha kell, erre mi is képesek va- 
gyunk. Ha olyan rendszerre telepítjük a clustert, amely 
nincs rajt a HCL-en, akkor a Microsoft részéről semmiféle 
segítséget nem kaphatunk. Tekintve a bekerülési költsége- 
ket és a felálló rendszer kritikusságát, ezt nem érdemes 
kockáztatni. A panelről az ,I understand" (Megértettem) 
gomb megnyomása után léphetünk csak a következőre. 

A fürttelepítő varázsló következő kérdése, hogy hányadik 
állomást telepítjük. Értelemszerűen kell válaszolni. Az első 
állomás esetén több teendője van a varázslónak, hiszen lét- 
re kell hozni a majdani ,közös tudást". Ha az első node-ra 
telepítjük a fürtöt, akkor meg kell adnunk a cluster nevét. 
A fürtnév az első virtuális kiszolgáló neve. A művelet végén 
egy olyan erőforráscsoport jön létre, amelybe a cluster ne- 
ve és IP címe, valamint a guorum disk kerül. Ezt a virtuális 
szervert adminisztrációs célokra kell használni, és bár le- 
het, én nem javaslom, hogy további erőforrásokat hozzunk 
létre benne. A fürt nevére a NetBIOS korlátok érvényesek. 
A következő lépés a fürtszolgáltatás fiókjának és jelszavá- 
nak megadása. Ha még nem adtuk meg a fiók jogait, akkor 
ezt a telepítő ellenőrzi. Figyelem! A varázsló a korábban 
felsorolt jogokból csak az első hármat adja meg automati- 
kusan, a többit meglévőnek feltételezi (vagyis, hogy 
Domain Admin a fiók). Ha nem akarjuk, hogy rendszergaz- 
da legyen, akkor a jogait előre be kell állítani. 

A fiókinformációk után a varázsló a felügyelt lemezekről ér- 
deklődik. A szakirodalom azt ajánlja, hogy minden lehetséges 
diszket azonnal rendeljünk a fürt felügyelete alá. Ez rendjén 
is lenne. A telepítés után viszont minden lemez külön cso- 
portba kerül, ami nem biztos, hogy kívánatos. Nosza átdobál- 
juk majd őket a megfelelő helyre. Csakhogy a , physical disk" 
erőforrás nem dobálható át úgy, ahogy azt gondoljuk. Előbb 
offline állapotba kell tenni, majd átmozgatni, majd újra onli- 
ne állapotba kell helyezni. Nálam még így is előfordult, hogy 
rejtélyes hibaüzenetet kaptam. A tudásbázis áttanulmányozá- 
sa után kiderült, hogy a lemezeket úgy kezeltem, mint bár- 
mely más erőforrást, és ez nem volt helyénvaló. Azt javaslom 
tehát, hogy csak a guorum disket hagyjuk a felügyelt lemezek 
között, és csak a telepítés után általunk létrehozott virtuális 
kiszolgálókhoz adjuk hozzá a többi lemezt. 

Itt érdemes megemlíteni, hogy a guorum disk legyen feltét- 
lenül dedikált, tehát ne használjuk semmi másra. A mérete 
legalább 50 MB kell, hogy legyen, a MS ajánlás 500 MB, 
amelyet érdemes betartani. 



































—— Nyilvános hálózat 

PC 
1. állomás 
Hub/Switch PC 
Magánhálózat 

PC 

——— Nyilvános hálózat 
2. állomás 95 


tech.net! 


WINDOows 2000 


A varázsló ezután sorra veszi a lehetséges hálózati kapcso- 
latainkat, és arra kér minket, hogy határozzuk meg, milyen 
szerepet szánunk nekik. Háromféle szerep létezik: magán- 
hálózat (private network), nyilvános hálózat (public net- 
work) és vegyes hálózat (mixed network). A fenti ábra se- 
gít eligazodni a fogalmak között. 

Amint az látható, egy normál fürtkonfigurációban minden 
állomás legalább két hálózati csatolóval rendelkezik. Az el- 
ső pár csatoló vagy egy hubon keresztül, vagy egy crosslink 
kábel segítségével közvetlenül van összekötve, míg a másik 
csatoló az ügyfelekkel tartja a kapcsolatot. A magánhálóza- 
ton olyan forgalom zajlik, amelyet a két állomás a folyama- 
tos szolgáltatás érdekében folytat. Ezek: a szerver szív- 
hang, az állapotinformációk replik. a, a clusterparan- 
csok, valamint a cluster működésre felkészített alkalmazá- 
sok állomások közötti kommunikációja. 

Ha a nyilvános hálózat egyben a magánhálózat forgalmát 
is bonyolítja, akkor azt vegyes hálózatnak nevezzük. A fen- 
tiekből következik, hogy a két hálózati csatoló nem köte- 
lező, csak nagyon ajánlott. Ajánlott továbbá, hogy ne nyil- 
vános hálózatot definiáljunk a magán mellé, hanem vegye- 
set, mert így akkor is zavartalan maradhat a clusterkom- 
munikáció, ha a magánhálózat valamilyen oknál fogva 
meghibásodik (egy Achilles sarokkal kevesebb). 

A magánhálózatok konfigurálásának további tudománya is 
van, amelyet a varázsló leállása után rögtön érdemes is al- 
kalmazni. Javaslom, hogy nevezzük át a kapcsolatot meg- 
jegyezhető névre (Pl. heartbeat) . A hálózatok beállításánál 
az úgynevezett Binding Ordernél a magánhálózatokat a 
nyilvános mögé kell sorolni, másodikként. A csatolót olyan 
címmel kell ellátni, amely nem fordul elő a nyilvános há- 
lózaton. (Ha pl. 10.x.x.x a hálózati cím, akkor a private net- 
work esetén használjuk a 192.168.0.x címeket, mindegyik 
állomáson természetesen mást.) Alapértelmezett átjáró, 
DNS és WINS bejegyzések ne legyenek a TCP/IP konfigurá- 
cióban, továbbá ki kell kapcsolni a NetBIOS-t is erre az 
adapterre vonatkozóan. (De csak erre!!) Ha crosslink kábelt 
használunk a magánhálózatban, akkor állítsuk be a követ- 
kező regisztrációs értéket: 





HKLMNSystemlCurrentcontrolsetlsServicesíTcpipV 
H, ParametersWDisableDHCPMediaSense 


REG DWORD, értéke: 1 


Ennek magyarázatát a 0254651 cikkben lehet megtalálni. 
Végezetül a TCP/IP beállító panel DNS fülén ki kell kap- 
csolni a , Register this connectorrs addresses in DNS" kap- 
csolót. Ha ezt nem tesszük, akkor a cluster regisztrálja a 
magánhálózat hálózati kártyájának címét is, amelytől vi- 
szont sohasem fog válasz érkezni a külső kérésekre, és ve- 
hetjük elő a Network Monitort, hogy megállapítsuk, miért 
nincs néha a cluster a hálózaton, amikor ott van. 

Térjünk vissza a varázslóhoz. Ha egy magán- és egy vegyes 
hálózatot adtunk meg, akkor még arra a kérdésre kell vála- 
szolnunk, hogy milyen sorrendben használja a szerviz a há- 
lózatokat a fürtforgalomra. Ezzel befejeződik a kérdezőskö- 
dés, a varázsló telepíti a szolgáltatást, elvégzi a regisztrá- 
ciós bejegyzéseket, és létrehozza a guorum disken a MSCS 
könyvtárban a guorum adatbázist. Ha mindent elvégzett, 
megpróbálja elindítani a fürtszolgáltatást. Az előkészítés 
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FARKASOKKAL TÁNCOLÓ 


(II. RÉSZ) CLUSTER A GYAKORLATBAN 


hány tíz másodperc elég arra, hogy észrevegyük, a cluster 
telepítésének inkább NT4-es formája és érzete van, mint 
Windows 2000-es. Ez a ,gyanú" később igazolódni fog: a 
Windows 2000-ben nagyon sok mindent átírtak, és nagyon 
sokat fejlesztettek, beleértve a clusterszolgáltatást is, még- 
is maradt jócskán tennivaló a következő kiadásig. 

A varázsló elvégezve feladatát leáll. Nekünk azonban akad 
további tennivalónk. Ellenőrizni kell, hogy a szolgáltatás 
valóban elindult-e, s ha igen, segíthetünk rajta, hogy ne 
nagyon akarjon többet állni. Vadonatúj Windows 2000-es 
szolgáltatás a szervizek működésének helyreállítása, és 
nemcsak a cluster szervizre. 














General] LogOn Recovery ] Dependencies ] 
Select the computers response if this service fail. 
First failure: Restart the Service mi 
Second failure: Run a File r 








Subseguent failures: 











Reset fail count after: o days 
Restart service alter: 1 minutes 
Run file 


Tsz eat 


TT Append fail count to end of command line [/fail-z122) 


Restart Cornputer Options. 
Cancel 


Command line parameters: 








Apply 








5 Windows szolgáltatások védelme 


Azt ajánlom, hogy még a virtuális szerverek üzembe állítá- 
sa előtt teszteljük a lehetséges helyreállítási eseteket. A 
cluster szerviznél a helyreállítás akkor fontos, ha vannak 
olyan csoportok, amelyek kizárólag egy állomáson futnak 
(például licencokok miatt), vagy maga a fürt egy állomás- 
ból áll (mert a másik csak jövőre érkezik) . Az újraindítás le- 
hetőségét csak akkor szabad igénybe venni, ha nincsenek 
fürtön kívüli szolgáltatások az állomáson, vagy azok más 
módon redundánsak. (pl. Active Directory) 

A teljességhez hozzátartozik, hogy két állomás esetén a má- 
sikon is le kell futtatnunk a varázslót. Ekkor már egy meglé- 
vő clusterhez kell csatlakoznunk, a szervizfióknak egyeznie 
kell az első állomásnál megadottal. A diszkekre vonatkozó 
kérés kimarad, mert azt a cluster adatbázis tartalmazza, vá- 
laszolni kell viszont a hálózati csatolók szerepét firtató kér- 
désekre. A sikeres csatlakozásról a varázsló jelentést tesz. 
Íme, megszületett a farkasfalka első tagja. A következő al- 
kalommal megismerkedünk a Cluster Administratorral és lét- 
rehozzuk az első virtuális kiszolgálóinkat. 


Lepenye Tamás (MCSE) 
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WINDows 2000 


Idő- 


szinkronizáció 


A Windows 2000 operációs rendszer alapértelmezett hálózati 
azonosítási protokollként a Kerberos V5-öt használja. Ennek 
tökéletes működéséhez az időszinkronizáció elengedhetetle- 
nül fontos, mivel a rendszer időbélyegeket (TimeStamp) 
használ a kiosztott , jegyeknél" (Ticket). Teszi mindezt azért, 
hogy ne lehessen a Kerberos Authentication Servert árverni 
hálózatból elkapott, és később visszajátszott csomagokkal. 
Ha az ügyfél és a kiszolgáló órája öt percnél jobban eltér 
egymástól, a bejelentkezés meghiúsul. Szerencsére a Win- 
dows 2000-ben az órák egyeztetéséhez szükséges szolgálta- 
tás előtelepítve megtalálható, melynek neve: Windows Time 
Service vagy - kicsit hétköznapibban - w32time. Ez a szolgál- 
tatás csendben teszi a dolgát, csak a kezdő rendszergazda 
őrül meg, hogy a hálózat egyik gépén képtelen beállítani az 
órát, mindig siet 9 órányit. Na az a gép Tijuana időzónájá- 
ban tanyázik, s a központi géptől vett pontos időt rendre el- 
tolja a saját időzónájának megfelelő értékkel. Az idő helyes- 
sége, az idő pontossága nem csak a Kerberos V5-nek fontos, 
hanem a csoportmunka egyik létfontosságú alapja is egyben. 


A pontos idő 

Előfordult már olyan a munkám során, hogy ,A" városban 
kiosztottak egy Outlook feladatot a , B" városban dolgozó 
kollegának. A két város közti távolság 200 km, a találkozó 
helyszíne , A" város volt. A ,B" városban dolgozó kolléga a 
KRESZ szabályait többször is áthágva taposta a gázpedált, 
hogy idejében , A" városba érjen, de hiába ért oda a meg- 
beszéltnek hitt 8 órára; a találkozót ugyanis 10:00-ra ter- 
vezték. Miért történhetett ez meg? A hibát nem a felhasz- 
nálóban kell keresni, és az idő pontatlansága sem okozhat 
ilyet. Azonban Einstein óta tudjuk: az idő relatív fogalom. 
Einstein ugyan még azt hitte, hogy a pontos idő a sebes- 
ségtől függ (minél jobban nyomja a kolléga a gázpedált, an- 
nál lassabban telik), de mi már tudjuk: bizony függ az az 
időzónától is. A pontos idővel kapcsolatban tisztázni fog- 
juk az időzóna szerepét, valamint megnézzük azt is, hogy a 
Microsoft Exchange kiszolgáló és az Exchange kliens pontos 
ideje között milyen összefüggés mutatható ki. 

Hogy a fenti eset senkivel ne fordulhasson elő, illetve 
egyetlen rendszergazdának se okozzon kellemetlen perceket 
egy ilyen helyzet, ajánlom cikkemet mindenki figyelmébe. 


Időzóna 

Magyarország kis ország, s ebből következően azt hihetjük, 
hogy ha Záhonyban is 11 óra van, meg Hegyeshalomnál is, 
akkor a világ minden pontján ennyi az idő. Aki sokat uta- 
zik, észreveheti, hogy a nap más pillanatban kel és nyug- 
szik itthon, Franciaországban és mondjuk Japánban. Bár 
ezek az apró jelek arra mutatnak, hogy a Föld gömbölyű, ezt 
mégsem kell tudnunk az időzóna fogalmának megértéséhez. 
Ha a Föld történetesen lapos, akkor is meg kell oldanunk a 
napfelkelték eltolódásának problémáját, amire az emberi- 
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ség azt találta ki, hogy ahol később kel a nap, ott később 
van reggel nyolc. A modern kompjútereken nem kell átte- 
kerni a mutatókat, hanem az operációs rendszernek meg le- 
het mondani, hogy vegye figyelembe helyváltoztatásunkat. 
Ezt az alábbi ábrán tehetjük meg. A kép alján bepipálható 
a téli-nyári időszámítás-váltás automatikus lekövetése, 
mely már 1996 óta nem okoz problémát a gépnek. (1995- 
ben még gond volt vele, lásd később...) 
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Date €eTime Time Zone ] 
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a Az időzóna beállítása 


Ide az időt! 

Mindenféle furfangos szolgáltatás nélkül is lehetséges a 
Windowsos számítógépek óráinak egyeztetése, csak a meg- 
felelő parancsot kell ismerni, és használni. A net parancs- 
nak egy alparancsa a time, aminek segítségével Windows NT 
és Windows9x alatt is elérhető a manuális időszinkronizá- 
ció. A net time használatával minden előzetes telepítés 
nélkül akármelyik géptől elkérhetjük a ,pontos" időt. Egy- 
szerűsített használata a következő: 


net time Nkiszolgáló /set /y 


Sajnos a bejelentkezett felhasználónak rendelkeznie kell a 
helyi idő megváltoztatásának jogával (Change the System 
Time). A net time a következő módokon használható még: 
2 Net time /set /y: a munkaállomás óráját a gép tartomá- 
nyában taláható valamely kiszolgálóval szinkronizálja 
2 Net time /domain:domain neve /set /y: a munkaállomás 
óráját a megadott tartomány valamely kiszolgálójával 
szinkronizálja 
Automatikus használata nehézkes, mert nem ritka, hogy a 
felhasználók nem rendelkeznek időállítási jogosultsággal, 
ámde mi mégis szeretnénk azt elérni, hogy a helyi időt rend- 
szeresen szinkronizáljuk egy általunk pontosnak vélt időki- 
szolgálóval. Az előző parancsok akár egy LogonScript-ben is 
használhatók, de ha nincs jog, nincs jog (a LogonScript a be- 
jelentkezett felhasználó jogosultságával hajtódik végre). 
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Lehet játszadozni a jogosultság megadásával, de előbb- 
utóbb az ember belefárad. Miért? Hát azért, mert a fent 
említett jogot minden egyes munkaállomáson helyileg kell 
megadni a felhasználóknak, azaz ha 500 gép van, akkor 
mind az 500-on! (Lokális SAM jog.) 

Ennek a problémának az elkerülésére valók a - szolgáltatás- 
ként futtatott - komponensek, amit a gépekre telepítve a be- 
jelentkezett felhasználó jogosultságától függettlenül ellátja 
az időszinkronizációs feladatokat. Így ha 500 gépünk van, ak- 
kor ,csak" 500 telepítést kell elvégezni, és készen vagyunk. 
Sokkal egyszerűbb, mint 500 jogosultságállítás nemde? 


RFC1305; RFC1769 (NTP; SNTP) 

A legnépszerűbb időszinkronizáláshoz használt protokoll az 
RFC1305-ben leírt Network Time Protocol (NTP) ami relatíve 
elég összetett, komplex alkalmazás. Az NTP egy speciális 
eszköz segítségével (például rádióadó, vagy műholdvevő) 
egy másik eszköztől ,elkéri" a pontos időt. Az NTP haszná- 
lata gyakorlatilag mikroszekundumos pontosság elérését te- 
szi lehetővé, természetesen az eredmény függ a pontos időt 
szolgáltató eszköztől és az ahhoz vezető elérési úttól is. Az 
NTP használata azonban nem szükséges olyan esetekben, 
ahol nem követelmény a mikroszekundumos pontosság. 

Az SNTP (Simple Network Time Protocol — RFC1769) egy olyan 
időszinkronizációs szolgáltatás, ami az NTP-vel szemben nem 
biztosít ekkora pontosságot. Azonban nem kell elkeserednünk: 
a pontosság itt is fontos és létezik, még ha nem is mikro, ha- 
nem milli az a szekundum. Az SNTP protkollt kimondottan ügy- 
fél-kiszolgáló hálózatok számára készítették és tökéletesítet- 
ték. (Az SNTP és az NTP teljesen azonos adatcsomagokat hasz- 
nál, azonban az SNTP nem támogatja a hibaellenőrzést.) 


NT Time Service és W32Time Service 

A Windows NT 4.0-hoz is be lehetett szerezni időszinkroni- 
zációs szoftvert, többek között a Resource Kiten találhat- 
tunk egy ilyet. A Windows 2000-be pedig, mint említettük, 
gyárilag ,beszerelték" ezt az extrát. A két szolgáltatás ter- 
mészetesen ugyanazt, azaz időszinkronizációt tesz lehető- 
vé Microsoft környezetben. Azonban a két eszköz néhány 
dologban gyökeresen eltér egymástól. A különbségeket 
meg kell ismernünk, továbbá ismernünk szükséges a koráb- 
bi időszinkronizációs eszközöket is, mert többnyire vegyes 
környezetekkel is találkozhatunk munkánk során. 

A tökéletes pontosság eléréséhez, vagy legalább a rendszer 
konzisztenciájának megőrzése érdekében ki kell jelölni a 
szükséges feladatokat kiszolgáló gépeket. Nem lenne sze- 
rencsés, ha a hálózatunk minden számítógépe azonos tu- 
lajdonságot hordozva képes lenne időkiszolgálóként mű- 
ködni, és egy esetleges kérést kiszolgálna. Ennek elkerülé- 
se érdekében az időszinkronizációs folyamat csak egy elő- 
re, jól definiált szabályrendszerben történhet meg. A kö- 
vetkező ábra szemlélteti a szinkronizációban részt vehető 
partnerek kapcsolati viszonyát. 
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0 NT TimeServ hierarchia 
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Elemezzük az ábrát! Minden NT TimeServ szolgáltatást fut- 
tató tartományban, vagy hálózatban szükséges legalább egy 
MASTER Time Server, egy PRIMARY Time Server és ezen kívül 
lehetnek még SECONDARY Time Serverek és egyszerű Time 
ügyfelek. A szabály szerint a MASTER Time Server egy, az 
Interneten keresztül elérhető Standard Time Provider-től ve- 
szi a pontos időt NTP protokollt használva. A PRIMARY Time 
Server a MASTER Time Serverrel áll kapcsolatban és tőle ké- 
ri el a pontos időt TCP kommunikáció során. A Secondary ki- 
szolgáló egy olyan kiszolgáló ami a Primary Time Server ügy- 
fele lehet (szintén TCP kliens). Time ügyfeleknek hívom azo- 
kat a munkaállomásokat, amelyek a net time parancsot 
használják a pontos idő elkéréséhez. Egy Windows NT 4.0 
Server is lehet Time ügyfél, ha nincs a gépre telepítve a 
TimeServ szolgáltatása, vagy az újabb W32Time szolgáltatás. 
A kliensekre (WinNT Wks.;Win2000) telepített TimeServ ese- 
tén Secondary-nek kell őket konfigurálni. Tehát mint láthat- 
juk, a szerepeknek igen fontos súlyuk van. De hol lehet beál- 
lítan, hogy melyik gép milyen szerepet tölt be? Az az időke- 
zelő komponenstől függ. Sajnos ilyenből több is van: 


1. A TimeServ szolgáltatás 
A korábbi időszolgáltatóban nem túl barátságos módja van 
a szerepek konfigurálásának. A timeserv.ini fájlt kell kéz- 
zel módosítani. A TimeServ szolgáltatás három fájlból áll: 
"6 TimeServ.exe: ez a futó alkalmazás, konfigurálást nem 
igényel. Helye a fájlrendszerben: 9Yosystemroot"otsystem32 
2 TimeServ.dll: az exe-hez tartozó dynamic link library. 
Konfigurációt nem igényel, azonban megléte fontos. 
Helye a fájlrendszerben: 9osystemroot9otsystem32 
TimeServ.ini: a konfigurációs fájl. A hierarchiában elfog- 
lalt szerepet ebben a fájlban határozhatjuk meg. Helye 
a fájlrendszerben: 9Vosystemroot9o 
A TimeServ.ini fájl testreszabásával a hálózatunkban hasz- 
nált hierarchiát alakíthatjuk ki. A képen egy példát látha- 
tunk egy TimeServ.ini-re: 


CANTZE TAN ENOGET] 
Ele Edit Format Help 
(Timeserv] 
Type-SECONDARY 

Periodz0 
jsecondarypomain-GENIUSGROUP 
Logsyes 

TaSync-no 





o TimeServ.ini 
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A Type paraméter megadásával beállíthatjuk, hogy milyen 
szerepet tölt be a gépünk. A lehetséges értékek: Master, 
Primary, Secondary. A Type-Primary esetében egy Primary- 
Source-tkiszolgáló sort kell beírni a SecondaryDomain sor 
helyére. A Type-Master esetében pedig az NTP Server-ntp 
kiszolgáló sort kell az ini fájlhoz hozzáadni. Az ini testre- 
szabása után telepíthetjük a TimeServ programot. Amennyi- 
ben a TimeServ.ini-t a szolgáltatás telepítése után módosít- 
juk, a szolgáltatást újra kell indítani ahhoz, hogy az érvény- 
re jusson (az újraindítás közben a szolgáltatás leállását köve- 
tően a timeserv -update parancsot kell futtatni). Közvetlenül 
registry-ből is konfigurálhatjuk a TimeServ szolgáltatást. A 


HKLMNSystemlCurrentControlSetlServicesN 


LanManServerlParameters 


kulcs alá létre kell hozni a TimeSource REG DWORD típusú 
értéket. A Registry módosítása után a gépet sajnos újra kell 
indítani. 


2. A W32Time szolgáltatás 

A Microsoft az Y2K javítások keretében egy új, a Windows 
NT 4.0-ra is telepíthető időkiszolgálót is kifejlesztett, ez a 
W32Time Server. A program néhány újítást tartalmaz a 
TimeServ 1.55-höz képest. A , type" már három lehetséges 
értéket vehet fel: NTP, Primary és Secondary. Az NTP a 
MASTER TimeServer-t jelöli a hálózatban, amiből több is le- 
het. A hálózatunk legfeljebb egy Primary kiszolgálót tartal- 
mazhat, ami az összes MASTER TimeServerrel szinkronizál- 
hat. A hálózat többi számítógépe pedig Secondary lehet. 
További előnye az, hogy hálózatunkban saját NTP kiszolgá- 
lót definiálhatunk a LOCALNTP-yes sorral. 

Nézzünk egy példát a funkciók definiálására. Az alábbi 
képen egy MASTER egy PRIMARY és egy SECONDARY 
w32time.ini fájlt láthatunk. Természetesen a MASTER 
esetén az NTPServer-NTPSERVER esetén az érték helyére 
egy NTPSERVER kiszolgáló címét kell megadni, ugyanez 
igaz a PrimarySource és a Secondarydomain-re is. 


CIZHENMELEETT TOL] 77 Loa a 

ES LGEEZÁTZ 

-jfpespathany 
perfod-o 








fRandonbr imaryeyes 
Ír imesourcesyes 


a W32Time.ini 


3. A Windows 2000 Time Server 

A Windows 2000-hez egy új fejlesztés vette kezdetét de az új 
időmunkás neve megegyezik a Windows NT 4.0 alá készült 
Windows Time Serverrel: W32Time. A W32Time előtelepített 
szolgáltatásként az operációs rendszer részévé vált (nem kell 
utólag 500 gépen telepíteni!). A szolgáltatás a gép indítása- 
kor elindul, a szinkronizálás automatikusan megtörténik. A 
W32Time kétféle módon képes szinkronizálni, ezek neve: NTP 
és NT5DS. Az NTP szinkronizáció során meg kell adni az NTP 
kiszolgáló nevét vagy IP címét. (A Windows 2000 is képes NTP 
kiszolgálóként működni. LOCALNTP-1) 

A W32Time SNTP-t használ az időszinkronizációhoz. 

NT5DS szinkronizáció során az Active Directory hierarchia 
szerint történik a szinkronizálás. A szinkronizálási hierar- 
chia a következők szerint alakul: 
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0 A gyökértartomány PDC Emulator FSMO tulajdonosa az AD 
erdő Authorative Time Servere. (Windows 2000 alatt a 
MASTER Time Servert Authorative Time Servernek nevez- 
zük.) Az Authorative Time Server-t egy külső NTP kiszol- 
gálóval szinkronizálni kell. 

0 A tartományban az összes tartományvezérlő a tartomány 
PDC Emulator gépével szinkronizálja az óráját. 

0 A gyermektartomány PDC Emulatora a gyökértartomány 
bármely tartományvezérlőjével szinkronizálhat. 

2 A gyermektartomány(ok) összes tartományvezérlője szink- 
ronizálhat a szülőtartomány bármely tartományvezérlő- 
jével vagy a gyermektartomány PDC Emulatorával. 

- Bármely tartomány bármely ügyfele a saját tartomány 
összes tartományvezérlőjével szinkronizálhat. 







Time server 
(Poc) 


A omain Domain 
Controller. adás 


Workstation roxfort.com 








Domain Domain 
Controller — Controller 


gringotts.roxfort.com 


a AD hierarchia 


Mint ahogy mondtuk, az Authorative Time Servert egy (vagy 
több) külső NTP kiszolgálóval szinkronizálni kell, mert ha 
nem tesszük, tele(s)írja az Event Logot. Ezt a Windows 
2000-ben debütáló új net time parancs segítségével tehet- 
jük meg a következő formában: 


net time /setsntp:kiszolgáló címe(i) 


A W32Time összes konfigurációs paramétere a Registry-ben 
tárolódik. A fenti parancs kiadása után az adatok a 


HKLMISystemlCurrentControlSetlServicesWw32TimetV 


Parameters 


kulcs alá kerülnek, így a kiszolgálók listáját nem kell újra 
és újra megadnunk: az már a registryben marad felülírásig. 
Meg kell említenem, hogy a TimeServ.ini és a W32Time konfigu- 
rációs lehetősége elég összetett. E cikk keretében nem az összes 
kapcsoló és funkció részletes bemutatását, hanem inkább a ter- 
minológia megértését tartottam szem előtt, ezáltal pedig a spe- 
ciális funkciók használatához szükséges kapcsolók a HELP fájlok 
és termékdokumentációk közül könnyedén kikereshetők. 
Ajánlatos legalább két különböző TimeServer-t megadni az 
Authorative Time Server számára, hibatűrő rendszer eléré- 
sének érdekében. Válogathatunk az Interneten található 
számtalan időkiszolgáló közül, vagy rácsatlakozhatunk a 
Microsoft által üzemeltetettre: time.windows.com. 
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A tűzfalakon természetesen a megfelelő portot ki kell nyit- 
nunk ahhoz, hogy kiszolgálónk szinkronizálni tudjon. Az 
NTP és az SNTP az UDP 123-as portot használják. Ezt min- 
denképpen át kell engednünk, ellenkező esetben a szink- 
ronizálás nem fog működni. 

Mint láthatjuk, a tartományvezérlők (DC) szinkronizációs 
partnereként több kiszolgáló is szóba jöhet. Mi alapján dönti 
el, hogy kivel fog szinkronizálni? Elég komplikált módon vá- 
lasztja ki. A következő algoritmus alapján dönti el, hogy kivel 
szinkronizál: amikor , ütött az óra", küld egy kérdést minden 
tartományvezérlőnek. Ezek válaszolnak neki a kérdésre, elkül- 
dik a kért infomrációt. A kérdés, és válaszok alapján eldönti, 
hogy a válaszoló géppel azonos telephelyen (Acitve Directory 
Site)-ban és tartományban van-e, vagy sem. Majd felállít egy 
sorrendet a tartományvezérlők között, ahol előnyt élvez a 
szülőtartomány tartományvezérlője a helyi tartomány tarto- 
mányvezérlőjével szemben. Plusz pontot ér, ha azonos telep- 
helyen vannak. E szerint a helyi tartományban, azonos Site- 
on levő tartományvezérlőt fogja választani a szülőtartomány- 
ban, de más telephelyen lévő géppel szemben. 


Munkaállomások és tagkiszolgálók 

A munkaállomás a hitelesítést végző kiszolgálóval kicserél 
néhány (száz) adatcsomagot a bejelentkezés során, amiből 
megállapítják a kettejük közt zajló kommunikáció időkéslel- 
tetését. A munkaállomás ezután lekéri a vekker állását. Ha 
a kapott pontos időhöz képest a rendszer órája késik, a 
munkaállomás az órát azonnal beállítja, utánhúzza. Ha a 
kapott időhöz képest a munkaállomás órája maximum két 
percet siet, a munkaállomás a következő 20 percben a rend- 
szer óráját lassítja. A lassítást úgy éri el, hogy az eltéréstől 
függően a következő értéket veszi az időmúlás alapjául: 1 
min-61-66 mp. Amennyiben az eltérés több, mint 2 perc, a 
munkaállomás azonnal beállítja a rendszerórát. (Ennek oka 
a következő: 2 min-120 mp, amennyiben 20 percen keresz- 
tül 66 mp-1 min akkor pontosan 2076 mp:-120 mp-2 min 
amit tudott a rendszerórán faragni. A Microsoft maximum 
1099-kal engedi a rendszeróra lassítását, ami a 66 mp-1 min.) 
A rendszeróra most már pontos, már csak a rendszeres 
egyeztetésről kell gondoskodni. Az első egyeztetés után a 
munkaállomás a rendszeróráját időközönként ellenőrzi. 
Alapértelmezésben ez 8 óránként történik meg. Amennyi- 
ben 8 óra után az eltérés mértéke nagyobb mint 2 másod- 
perc, az ellenőrzések számát megkétszerezi, azaz a lekérési 
időt a felére csökkenti (4 óra). Ha az eltérés 4 óra múlva is 
meghaladja a 2 másodpercet, az idő felezését addig folytat- 
ja amíg a két ellenőrzés közti időszelet el nem éri a 45 per- 
cet. Amennyiben kevesebb mint 2 másodperc az eltérés, az 
órát azonnal beállítja. A 45 perces küszöböt elérve pedig 
addig tartja ezt a gyakoriságot, amíg az eltérés nem lesz 
kevesebb, mint 2 másodperc a szinkronizálási idők között. 


Down-Level ügyfelek időszinkronizációja 

A Windows NT Workstation gépek mind a TimeServ, mind 
pedig a W32Time szolgáltatás futtatására képesek (a 
type-Secondary értéket megadva). Vegyes környezetben is 
a type-Secondary értéket kell használni. 

Meg kell jegyezni, hogy Windows9x-nél a net time parancs 
hibás: ha a kiszolgáló és a kliens gép különböző időzónában 
van, nem működik megfelelően. Például ha a kiszolgáló idő- 
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zónája GMT, a munkaállomásé pedig GMT--1, és a szinkroni- 
záláskor GMT idő szerint 10:00 a pontos idő, a kliens GMT--1 
időzónában is 10:00-ra állítja be az időt - azaz nem veszi 
figyelembe az időzónát. A helyes idő GMT--1 szerint ekkor 
már 11:00. A Microsoft kijavította a nyilvánvaló hibát, és a 
Microsoft Windows 98 Resource Kit lemezén közzéadta. A 
nettime.exe és az rtzone.exe programot egyszerűen be kell 
másolni a 9oSystemRootyolSystem32 könyvtárba (plusz új- 
raindítás). Az új nettime.exe program használata során a 
/set /y kapcsolókat nem szükséges megadni. 

Ha már kliens és hiba, akkor meg kell jegyezni egy másikat 
is. A Windows 95 első, minden Service Pack nélküli változa- 
ta - amiből reményeim szerint már nem fut olyan túlságo- 
san sok - a téli időszámítás időpontját elvéti. Szeptember 
utolsó vasárnapját követően ő bizony átáll. Ezt pontosan 
egy hónappal korábban teszi meg mint kellene, s ekkor egy 
érdekes eset fordul elő. A hálózatban levő Windows NT és 
Windows 2000 gépek még nyári időszámításban számolnak, 
a Windows 95 pedig már téliben. Ilyenkor sajnos - függet- 
lenül az időzónától - eltérés lesz a munkaállomások és a ki- 
szolgálók között is. (A téli GMT:-1 10:00 bizony GMT--1 9:00- 
nak felel meg nyári időszámításban.) Ez már elég kaotikus- 
nak tűnik, s ha még hozzávesszük azt is, hogy a Windows9x- 
ek az időzónától függően rosszul szinkronizálják a helyi órá- 
jukat, nem biztos, hogy meg tudjuk válaszolni a klasszikus 
kérdést: mennyi az idő most......? A hiba javítása egyszerű: 
az rtzone.exe programmal le kell gyártani az egyedi időzó- 
nát amiben a helyes dátumra javítjuk a téli időszámítás átál- 
lását, s az új időzónát terjesztjük a munkaállomásokon. 


Ügyfél-kiszolgáló alkalmazások és a pontos idő 

A csoportmunka talán a legkényesebb a pontos idő haszná- 
latára. . Csoportmunka — megoldásokat legkönnyebben 
Exchange kiszolgálók segítségével vehetünk igénybe. 
Exchange kiszolgáló esetében a levelek küldési- és fogadási 
ideje abszolút időben mérődik. Ez azt jelenti, hogy ugyan 
ott van az időpont, de ez nem tartalmazza az időzónát. 
Ezért ha az időzónát átállítjuk, a levél küldési- és fogadási 
ideje is az időzónához igazodik, látszólag eltolódik. Ez érin- 
ti a feladatok kiosztását is, mert ha kiosztunk egy feladatot 
GMT--1 10:00-ra az GMT--2 időzónában megnézve 11:00 lesz, 
természetesen GMT--2 szerint. Egy kis matatás az időzóna 
beállítások között, s máris átkerül a megbeszélés tíz óráról 
lentkezik, tehát fontos, hogy a munkaállomások azonos idő- 
pontban váltsanak a téli és nyári időszámítás között. 
Félreértés ne essék: az Exchange teljesen logikusan és egysé- 
gesen kezeli az időket, a felhasználók trehánysága miatt előál- 
ló virtuális késések és sietések lekezelése nem az Exchange 
Server feladata. Ha butaságot kérnek tőle, butaságot mond. 
Az Outlook lehetőséget biztosít, hogy két időzónát hasz- 
náljunk, de egyidőben akkor is legfeljebb egyet, ráadásul 
a módosítás nemcsak az Outlook által használt Időzónát 
állítja át, hanem a rendszerét is. 5 


Harmath Zoltán 
zoli ogeniusgroup.hu 
MCSE, MCP4I 
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Ez a cikk nem azonnal az útválasztási protokollokkal kezdő- 
dik, mert meg kell emlékeznünk a szeptemberi számból ter- 
jedelmi okokból kimaradt útválasztási hibákkal, melyek 
szinte minden hálózaton felbukkannak előbb-utóbb. Csak 
ezek után térünk rá a RIP útválasztási protokollra. 


Útválasztási anomáliák 

Három esetet veszünk szemügyre: 
1. Forgalmazás belső IP címekről 
2. Hamis IP címek használata 

3. Körkörös routolás 


1. Forgalmazás belső IP címekről 

Ez az útválasztási , hiba" többnyire nem szokott galibát okoz- 
ni, mert akik tudatosan használják a belső IP címeket hálóza- 
taikban, nem lepődnek meg azon, hogy ezeket a nagyvilágban, 
kint az Internet backbone-on nem fogadják el a routerek. Mely 
címekről volna szó? A 10.0.0.0/8, a 172.16.0.0/16, és a 
192.168.0.0/16 tartományok címeiről, melyek a 1597-es RFC 
(tech.net 2000 október) szerint arra vannak fenntartva, hogy 
saját hálózatunkon szabadon használjuk őket. Ennek a szabad- 
ságnak egyenes következménye, hogy a világban számtalan 
számítógép fut például a 172.16.0.1 címmel. IP cím ütközés 
azért nem lép fel közöttük, mert sohasem kerülnek közvetlenül 
kapcsolatba egymással - kizárólag címfordítás útján érintkez- 
hetnek. A címfordítást például az első részben elemzett NAT 
biztosíthatja. Tipikus hibakeresési zavar, amikor valaki szóvá 
teszi, hogy belső IP című gépéről nem tud kipingelni, bár min- 
den más zavartalanul működik. Mi a hiba oka? Semmi. Nincs 
hiba, a NAT-ok, Proxyk a legritkább esetben emelik át az ICMP 
(Ping) csomagokat. Ne pingeljünk külső címekre. 


2. Hamis IP címek használata 

Ritkán fordul elő véletlenül, de praxisomban jött már 
szembe" velem olyan hálózati csomag, mely hamis IP cím- 
ről érkezett. Az IP útválasztás meglepően hasonlít a hagyo- 
mányos postai kézbesítésre: hamis feladóval éppúgy célba- 
juttathatunk IP csomagokat, mint postai levelezőlapokat. A 
postás bácsi csak a címzett címére összpontosít. S mint a 
való életben, a hamis címzés az IP csomag esetében is csak 
válaszoláskor okoz galibát: hova vigye a postás a személye- 
sen a télapótól kapott levélre írt válaszlevelemet? Hamisí- 
tott, de létező feladó (President George W. Bush) esetén pe- 
dig a válasz a gyanútlan harmadik félnél köt ki. Kéretlen 
(válasz) csomagok érkeznek egy gépre? Valószínűleg valahol 
valaki visszaél a mi IP címünkkel! 
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IP: 133.133.133.133 


a Hamis IP címről érkezett csomagra választ a cím gya- 
nútlan tulajdonosa kap! 


Volna az IP-ben lehetőség arra is, hogy a hamis IP címről 
érkező csomag mégis a hamisítóhoz jusson vissza. A megol- 
dás (source routing) lehetővé teszi, hogy egy csomag az 
eredeti feladó által meghatározott úton jöjjön vissza, ha- 
sonlóan az elektronikus levelezés "reply-to" megoldásához. 
Ezzel a technológiával azonban gyakorlatilag sohasem ta- 
lálkozunk, mert minden jólnevelt útválasztó eldobálja a 
source routinggal , felszerelt" csomagokat. Hogy miért? 
Mert az ezzel kapcsolatos hekkelések már évek óta ismertek. 
A hamis IP cím azonban így is visszaélésekre adhat alkalmat, 
egyfajta DDOS támadás kivitelezhető vele: ha egyszerre ezer 
gép áll neki egyetlen másik nevében pingelni össze-vissza a 
neten, akkor az áldozat (akinek az IP címét felhasználták) a 
világ minden sarkából elkezd kéretlen ICMP Reply-ket kapni. 
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5 DDOoS támadás az áldozat IP címének használatával. 
(Ez megmagyarázza, miért kap Bush elnök évente több 
tízezer levelet... :-) 


tech.net! 


WINDOws 2000 RRAS 
Így járt tavaly kora tavasszal a Yahoo!, az e-Bay és a többiek. 
A nyomozás rendkívül nehéz, ugyanis minden csomag úgy néz 
ki, mintha valóban az áldozat adta volna fel a kérést. Most 
nem tippeket óhajtottam adni, hanem rávilágítani, hogy mi 
mindenre ,jó" egy kis szemfüles ravaszság, hogyan válik fegy- 
verré minden. Régebben erre azt mondták volna, hogy elsült a 
kapanyél. Ma csak annyit mondunk: World Trade Center. 


3. Körkörös routolás 

A NetMon sorozat egyik részében már kitértem erre a je- 
lenségre, amely akkor fordul elő, ha egy hálózatban az 
alapértelmezett útvonalak hurkot zárnak be, és egy háló- 
zati csomag olyan címre irányul, amely ismeretlen minde- 
gyik útválasztó előtt. Ebben az esetben ugyanis mindegyik 
a 0.0.0.0 útra küldi az ismeretlen csomagot, mely - digitá- 
lis jel lévén - a végtelenségig keringhetne a hálózatban, 
ha valaki, vagy valami meg nem fogná. Emlékeznek még? 
A TTL (Time to Live) számláló csökkentése révén az IP cso- 
magok csak egy maximális számú útválasztóátlépésre ké- 
pesek. Mivel mindegyik router csökkenti a TTL-t, előbb- 
utóbb ennek értéke nullára fut, s a csomag elhal. 


Útválasztási protokollok - a Routing Information Protocol 
Az előző részben eljutottunk odáig, hogy kézzel képesek vol- 
tunk módosítani az útválasztók útvonaltábláit. Szép dolog, 
hibakereséshez kell is ez a tudás, de egy összetett vállalati 
hálózat útvonalterveinek kiszámításához és megvalósításá- 
hoz nem árt, ha számítógépeinket is segítségül hívjuk. A RIP 
protokoll telepítsd-és-felejtsd-el módon működik. Csak felha- 
jigáljuk a megfelelő gépekre, és a tudás (alhálózatok és átjá- 
rók ismerete) szétterjed az egész hálózatban. Telepítés után 
még meg kell mondani neki, hogy mely hálókártyákon dol- 
gozzon, és már megy is. A beállítások erdejét lásd később. 
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dd a new routing protocol 


0 A RIP telepítése 


Gyönyörűen működik, nem hiába a Xerox találta fel ezt is. 
Ugyanakkor routerguruk szájából mást hallani: a RIP így nem jó, 
a RIP úgy nem jó, és nagy hálózatokon teljesen használhatat- 
lan. Most akkor jó, vagy nem jó? Vizsgáljuk meg a működését! 
Minden router ismeri a belőle kimenő vonalakat, valamint azt 
az IP címet, amely az adott alhálózaton a gateway (ezt ele- 
mezgettük a route print paranccsal). A RIP az útvonalak 
hosszát az úgynevezett hop counttal méri, mely a route print 
kimenetében a Metric mező. Ha beteszünk egy hálózati kár- 
tyát egy gépbe, azon automatikusan 1-re állítódik a Metric, 
azaz minden olyan masina, ami azon a kártyán közvetlenül 
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elérhető, 1 hopra van tőlünk. A Metric nem a bedugaszolt 
kártya tulajdonsága (bármennyire is annak tűnik), hanem a 
rajta keresztül elérhető hálóé - így áttételesen az azon talál- 
ható közvetlen szomszédainké is. Most vegyünk fel három út- 
választót az alábbi ábrán látható módon. Mi történne, ha 


ezek elmesélnék egymásnak, mit látnak a világból? 


2.2.2.0.0/24 


3.3.0.0/16 


4.4.4.0/24 


LEMEZEN RouterB LENEs 





Router Print: 
4.4.4.0 Metric 1 
3.3.0.0 Metric 1 
2.2.2.0 Metric 3 


Router Print: 
3.3.0.0 Metric 1 
4.4.4.0 Metric 1 
2.2.2.0 Metric 2 


Router Print: 
2.2.2.0 Metric 1 
3.3.0.0 Metric 1 
4.4.4.0 Metric 2 


-5 Három pletykás vénasszony. A vastaggal jelölt soro- 
kat a szomszéd súgta. 


RouterA elmondaná RouterB-nek, hogy lát egy 2.2.2.0/24 és 
egy 3.3.0.0/16 hálózatot. RouterB meghallgatja a történetet, 
a 3.3.0.0/16-ot nem veszi figyelembe, mert azt ő is tudja, de 
felveszi a 2.2.2.0/24 hálózatot az útvonaltáblájába, úgy, hogy 
a Metricet megnöveli eggyel. Nála a 2.2.2.0/24 útvonal 2-es 
Metriccel szerepel majd. Ezután pletykás vénasszony módjára 
továbbmondja RouterC-nek, hogy van ám egy 2.2.2.0/24 há- 
lózat tőle 2 hopra, aki immár 3-as Metriccel jegyzi be, hisz a 
2.2.2.0/24 hálózat tőle már 3 hopra van. A RIP-es gépek fix 
időközönként elküldik egymásnak teljes útvonaltáblájukat, 
benne saját, és ,tanult" (az ábrán vastagított) bejegyzésekkel. 
Az eredeti RIP alapértelmezésben 30 másodpercenként jelentge- 
ti társainak a saját világképét, mégpedig Broadcast címzéssel, 
hisz nem tudhatja, hogy egy adott subneten hány érdeklődő 
akad a bejelentésre. Ez az ő egyik legnagyobb baja. Hány gép- 
hez jut el a RIP üzenet? Mindhez. És switch esetén? Mindhez. A 
hálózati nyomtatóhoz és a kenyérpirítóhoz is? Igen. Ha egy út- 
vonal megváltozik, akkor a 30 másodperces ütemezésen belül is 
indulnak úgynevezett triggerelt üzenetek a partnerek felé. 


Konvergencia 

A RIP maximum 15 hop átmérőjű hálózatokhoz való azon egy- 
szerű oknál fogva, hogy a szabvány szerint ami 16 hopra, vagy 
annál messzebb van, az ,unreachable". (Egyes felmérések sze- 
rint a földgolyó 17 hoppal bármilyen irányban körbejárható. En- 
nek ellenére a RIP a maga 15 hopos korlátjával csak picike háló- 
Zatokra való.) A 15-ös korlátozást azért kellett bevezetni, mert 
bizonyos hálózati hibákra a RIP igen furcsán reagál: ahelyett 
hogy egy router kiesését hipp-hopp észrevenné, a lenti ábrához 
hasonló hálózatban RouterC kiesésével RouterA és RouterB azt 
fogja hinni, hogy a közvetlen vonal ugyan megszakadt 
RouterD-hez, de egymás segítségével (RouterA RouterB-n ke- 
resztül, RouterB pedig RouterA-n át) mégis eljutnak oda. 





o A világ RouterA szemüvegén keresztül. Egy közbülső 
útválasztó halála esetén a RIP alternatív útvonalakat 
vél felfedezni ott is, ahol nincsenek! 
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Ennek a viselkedésnek az az oka, hogy a RIP mindig a legol- 
csóbb útvonalat veszi figyelembe, és amíg RouterC élt, addig 
RouterA a RouterB által ajánlott kerülőutat nem veszi figye- 
lembe. Amint azonban RouterC meghal, mindjárt a 2 hopos, 
RouterB-n keresztülvezető kerülőút lesz a legolcsóbb, s 
RouterA figyelembe is veszi - sajnos nem a szakadás győz. És 
ami a legfurcsább, RouterA és RouterB innentől tanítgatják 
egymást a rég halott RouterC nemlétező útvonalával. S ahogy 
egymás fülébe súgják (,te, én azt hallottam, hogy van út 
RouterD-hez"), mindig hozzáadnak egyet-egyet a hopcount- 
hoz, míg az el nem éri a 16-ot, és akkor VÉGRE kiesik a nem- 
létező út a pici agyukból. Ezt a jelenséget Counting to 
Infinitynek hívják, és igen bosszantó, mivel a hálózati hibák 
észlelése emiatt meglehetősen lassú. A konvergenciaproblé- 
mára van megoldás, lásd később. Mérgezett alma... 

A RIP eredeti verzóját azonban nem a broadcastolás és a 
lassú konvergencia miatt felejthetjük el, hanem a boldog 
békeidők miatt. Amikor ez a szabvány készült ([1], 1988), 
még nem voltak fogyóban az IP címek, és senki sem gon- 
dolt arra, hogy egyszer majd az A, B és C osztályú IP cím- 
tartományokat a subnet mask bitjeinek beállítgatásával ri- 
pityára fogjuk szabdalni (lásd CIDR, azaz Classless 
InterDomain Routing, [31). Íme a RIP csomag felépítése: 











command version must be zero 
Address family identifier must be zero 
IP address 


must be zero 





must be zero 








metric 
(az utóbbi négy sor ismétlődik max. 25-ször) 








A RIP eredeti verziójában kérem szépen nem szerepel a 
routerek közötti forgalomban az egyes hálózatok subnet 
maskja! De hisz ez így használhatatlan! 


RIP v2 

1994-ben látott napvilágot a RIP második verziója [2], 
mely már figyelembe veszi a CIDR-helyzetet, nemcsak Broad- 
castolni tud, hanem Multicasttal is képes értesíteni a többi 
routert, továbbá némi szekuriti is van benne - no nem túl 
sok, egy kevés klírtext jelszó, védelem". Az a döbbenetes a 
RIPv2 csomagformátumában, hogy annak dacára, hogy cso- 
mó mást is tartalmaz, mint amiről a RIPv1 valaha is álmo- 
dott, kompatibilis az előddel, azaz RIPv2 csomagokból 
RIPv1 útválasztók tanulhatnak! Az IP cím utáni ,must be 
zero" mező viszi a subnet maskot. Ez a gyönyörű az 
Internetben: a zökkenőmentes haladás, és az elődök szelle- 
mének tiszteletben tartása. Az új RIP, mint említettük, Mul- 
ticastolni is tud, mégpedig a 224.0.0.9 címen. Az alábbi 
ábrán - egy kis csalással - megjelenítettem az RRAS-féle 
RIPv2 Interface tulajdonságlapjának első oldalán az összes 
beállítást. A csalás lényege, hogy egyszerre sikerült legör- 
dítenem az összes kombót. Ezt csinálja utánam valaki! 
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RIP Properties - Local Area Connecti 


General ] Security ]) Neighbors ] Advanced ] 


b 


A 


JA 


Aj 


És 


PROTOKOLLOK 


212] 


Tét Routing Information Piotocol (RIP) Inteface 





Outgoing packet prot 
RIP version 2 brosdcast :] 


(RIP version 1 brozdcast 
RIP version 2 multicast 
Silent RIP 


Incoming packet protocot 




















RIP version 1 and 2 dani 
ignore hete 
RIP version 1 only 
RIP version 2 only 
Added cort for routes: (NE! 
eg for announced toutes: Pp a 
TT Agtívate authentication 

Ét ÍS ET 

Cancel Apply 


A RIPv2 beállításai 


Operation mode: ez a görgettyű állítja be, hogy RIP 
routerünk részt vegyen-e a 30 másodpercenkénti perio- 
dikus üzenetküldésben. Auto-static update módban 
csak és kizárólag RIP Reguestekre válaszol, Periodic 
Update módban önként elárulja minden titkát 
Outgoing packet control: itt lehet beállítani, hogy - ha 
egyáltalán megszólal - hogyan tegye. RIPv1 nyelven csak 
Broadcastolni tud, és ne feledjük, búcsút mondhatunk a 
subnet mask átvitelnek. RIPv2-ül már két módon (Broad 
és Multicast) beszélhet, míg a Silent RIP azt jelenti, hogy 
csak hallgatózik és tanul, de senkinek nem mond semmit. 
Incoming packet control: mely bejövő csomagtípusokra 
reagáljon. 
Added cost for routes: ennyit ad hozzá a beérkező útvo- 
nalak hop countjához (Metric) mielőtt beveszi az útvo- 
naltáblába. Emiatt ez az implementáció minimum 3-as 
Metriccel veszi fel a tanult sorokat. 
Tag for announced routes: itt két bájtunk van, ahova bár- 
mit beírhatunk. Eredetileg a RIP üzenet forrásának tipizálá- 
sára való (külső-belső) de jobbára semmire sem használjuk. 
Activate authentication: egyfajta hamis biztonságérzetet 
adhat ez a jelszómező. Minden RIPv2 útválasztón egyfor- 
mán kell kitölteni - ha kitöltjük egyáltalán. Arra való, 
hogy csak a jelszó birtokosaival replikáljon routerünk. 
Csakhogy a jelszó klírtext, vagy más néven ASCII titkosí- 
tással (értsd: olvashatóan) kerül ki a hálóra. Nem sok ér- 
telme van. Ennél sokkal többet ér a Security és a 
Neighbors fül, ahol explicite be lehet állítani, hogy kik- 
nek küld, kiktől fogad, mely útvonalakat tesszük esetleg 
tiltólistára, hogy még véletlenül se íródjanak felül. 
végül az Advanced fül: 
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General] Securily ] Neighbore Advanced l 


Periodic announcement interval (seconds): da 
Iime before routes expire (seconds). 180 3 
Time before route is removed (seconds) 120 








FF. Enable spltthorizon processing 

[7 Enable poisoneverse processing 
F7. Enable kiggered updates 
[7 Send clean-up updates when stopping 


TT Pitogess host routes in received announcemenis 





st routes in sent announcements 





TT Pigcess delault routes in received announcements 
IT Include default routes in sent announcements 


7. Digable subnet summarization 











5 A RIP matematikája 


Periodic announcement interval: itt módosíthatjuk eset- 
leg az alapértelmezett 30 másodpercenkénti értesíté- 
seket (nem ajánlott). 
Time before routes expire: ez a szám az útvonalbejegyzé- 
sek TTL-je. Ha ennyi másodpercig nem frissíti a partner, 
érvénytelennek kell tekinteni. Azonban ekkor még nem 
törlődik, hanem mint ,érvénytelen" kerül továbbadás- 
ra, hogy a többi partner is érvényteleníthesse 
0 Time before route is removed: a végleges törlés késlel- 
tetése 
A most következő két pipa külön alfejezetet érdemel. Em- 
lékszünk még az egymást badarsággal traktáló RouterA és 
RouterB esetére? Az útvonaltáblák trükkös továbbításával 
elkerülhető lenne ez a helyzet. Erről szól a horizontvonal, 
és a mérgezett alma. 


Split horizon és poisoned update 

Nagyon egyszerű elmagyarázni a horizontvonal-trükköt: az 
ezzel a beállítással futó RIP routerek nyilvántartják, hogy 
melyik útvonalat kitől tanulták. Ha csak ezt pipáljuk be, úgy 
kürtölik szét tudásukat, hogy a tanítónak sohasem felesel- 
nek vissza. Vagyis ha RouterA éppen RouterB-től tanult va- 
lamit, akkor azt az útvonalat oda nem mondja vissza. Ezzel 
elkerülhető egymás fokozatos elléptetése 16 hopig, amikor 
is végre megáll az őrültség (elérjük a végtelent. 00 - 16). Ez 
a trükk kiegészíthető a mérgezett almával (poisoned 
update). Ekkora tanuló visszamondja a leckét a tanítónak, 
de úgy, hogy ,amit tőled tanultam az nem létezik", vagyis 
minden megtanult útvonalat 16-os Metriccel, azaz elérhe- 
tetlenként mond vissza (a végtelen ugye elérhetetlen?) 


A cikkben szereplő URL-ek: 
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Mindaddig, amíg az eredeti út létezik, ez a mérgezett 
visszafeleselés nem változtat semmit a működésen, mert a 
tanár az eredeti útvonalat tekinti érvényesnek, hisz az 
nyilván közelebb van, mint amit a nebuló állít. Amint 
azonban RouterC meghal, és az eredeti útvonal megszakad, 
a nebuló által közölt végtelen lesz a legközelebbi út, s nem 


egyenként lépkedve érik el a 16-ot, hanem , azonnal". 


Összegzés 

Minden problémája ellenére használjuk bátran a RIP proto- 

kollt kis és közepes hálózatokon, mert a telepítsd-és-fe- 

lejtsd-el működés iszonyatos mértékben csökkenti a TCO-t. 

RIP: amivel nem kell foglalkozni! Csak működik és kész. 

Menthetetlen hátrányai: 

"0 Nagyobb hálózatokban (10-12 hop) az azonnali konver- 

gencia percekig tart 

Vannak olyan - ismert és elkerülendő - hálózati topoló- 

giák, ahol nem használható, mert hurkot csinál 

2 Nagy hálózatok esetén (alhálók száma - 25) elég jelen- 
tősen nő az egyébként minimális sávszélességigénye, 
mert komplett útvonaltáblákkal dobálódzik 


Ja 


Miért? Van más? 

Van bizony! Vannak olyan útválasztó protokollok, melyek 
tetszőleges nagyságú hálózatra alkalmazhatók, nem a 
komplett útvonaltáblát küldik szét, csak a vonalak állapot- 
információit (link state), amelyek mindig pillanatok alatt 
konvergálnak, amelyek sohasem hoznak létre hurkot, ame- 
lyek esetén kolbászból van a kerítés. Az egyik ilyen ütőké- 
pes protokoll az OSPF (Open Shortest Path First), mellyel a 
következő RRAS cikkben foglalkozom részletesebben. Ad- 
dig is egy kis fejtörő: ha az OSPF annyival jobb, mint a 
RIP, miért nem mindig azt használjuk? 


Megfejtés. Mert az OSPF: 

"0 bevezetése tervezést igényel (a hálózatot mérettől füg- 
gően Area-kra kell bontani) 

-? bonyolult matematikán alapul, amit ha érteni nem is kell, 
de a létezésének felismeréséig el kell jutni 

"2 nem csökkenti a TCO-t, azaz telepítés után is pátyolgatást 
igényel(het) 

"B a bonyolult matekozás miatt sok memóriát és processzor- 
időt igényel(het) 


Fóti Marcell 
marcellf-onetacademia.net 
MCSE, MCT, MCDBA, MZ/X 


[1] A RIP prorokoll. RFC 1058, http://www.ietf.org/rfc/rfc1058txt 
[2] A RIP version 2. RFC 1723, http://www.ietf.org/rfc/rfc1723txt 
[3] CIDR (Classless InterDomain Routing). RFC 1467, http://www.ietf.org/rfc/rfc1467txt 
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Remote 


Installation Services 


Aki olvasta az előző RIS cikket a novemberi számban, az 
már tudja mi is a RIS, milyen ügyfél- és kiszolgálóoldali 
összetevői vannak. Nem fog bambán nézni ha ezeket hallja 
PXE, rbfg, risetup. A telepítés és alapvető beállítás talán 
nem jelent problémát számára. Igen sok nyitott kérdés ma- 
radt azonban, amiről mindenképp szót kell ejteni. Ebben a 
részben szó lesz arról, mit tett a telepítés a kiszolgálóval, 
hogyan tudunk több telepítőkészletet használni, valamint a 
RIS kiszolgáló karbantartásáról. Ott tartottunk hogy felte- 
lepítettük a RIS szolgáltatást, beállítgattuk a legalapvetőbb 
dolgokat a risetup varázsló segítségével, majd hitelesítet- 
tük a RIS kiszolgálót a tartományban. 

Nézzük meg először mit művelt a telepítés a RIS gépen! 


RIS kiszolgáló a beállítások után 

Risetup futtatása után három új szolgáltatást találunk a 

Services MMC-ben nézelődve: 

0 Boot Information Negotiation Layer szolgáltatás - röviden 
BINL. Ez adja meg az ügyfeleknek a telepítéshez szüksé- 
ges állományok nevét, ő kezeli az ügyféltelepítő varázsló 
(Client Installation Wizard - CIW) képernyőit; tehát vele 
beszélgetünk, mikor a varázsló képernyőinek válaszolunk 
a telepítés elindítása előtt. BINL szolgáltatás beszélget a 
tartományvezérlővel arról, van-e egyáltalán jogunk gépet 
beléptetni a tartományba, mi a helyzet a csoportos házi- 
rendekkel, ő közvetíti a munkaállomásoknak, hogy milyen 
telepítőkészletek elérhetők a kiszolgálón, és létrehoz egy 
SIF kiterjesztésű állományt a RemoteinstallTemp könyv- 
tárban az adott ügyfél telepítéséhez. 

"0 Trivial FTP Daemon szolgáltatás - Az ügyfelek ennek segít- 
ségével töltik le a szükséges állományokat, a CIW képernyő- 
ket és a Windows 2000 Telepítő indulásához szükséges ál- 
lományokat. Azért használható jól erre, mert neki nem kell 
megadni felhasználói nevet és jelszót, amikor le akar töl- 
teni egy adott helyről, mint a hagyományos FTP esetén, és 
rendkívül gyors, mert IP protokoll fölött UDP-t használ 
(míg a hagyományos FTP TCP protkollt) az adatátvitelre 
(mint ismeretes, az UDP nem érdeklődik a csomagok után 
hogy az megérkezett-e a címzetthez, hanem mindent el- 
lenőrzés nélkül villámgyorsan küld át a hálózaton). 

0 Single Instance Storage Groveler szolgáltatás - röviden SIS 
amely uralma alá vonja az egész partíciót amelyre a Remo- 
telnstall könyvtárat létrehozta. Az ő feladata biztosítani, 
hogy minden egyforma fájl csak egyszer forduljon elő a 
partíción (ha minden image tartalmazza ugyanazt a fájlt, 
akkor is csak egy példányban tárolódjon) . Igazi csemege ez 
a szolgáltatás, kár hogy RIS-től külön nem telepíthető. 

A Remoteinstall könyvtárat tartalmazó partíción létrejön a 

következő könyvtárstruktúra: 
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6-4) Remotelnatak 
B Admin 
21 1386 
E-2J OSChooser 
I Engieh 
1) 286 
5. 3FEd 
3] Enge 
BI Imager 
BI vinz000 pro 
8.21 886 
2 sytemő2 
I template 
I urigtoe 
I tag 


0 A Remotelnstall könyvtár szerkezete telepítés után 


Remotelnstall - A távoli telepítésekhez tartozó összes minden 

ez alatt a könyvtár alatt található. Ez a könyvtár Reminst néven 

meg is van osztva. Ez a hely a TFTP gyökérkönyvtára is, azaz 
amikor a PXE ügyfél a rendszerindítási folyamat során kapcsoló- 
dik rendszerállományának letöltéséhez, ez lesz a főkönyvtára. 

Admin - Ez a könyvtár tárolja az összes segédprogramot, 

ami a RIS kiszolgálóval kapcsolatos. Az Admin/i386 könyv- 

tárban a következő programokat találjuk: 

2 Riprep.exe - az ő segítségével kreálhatunk egy előkészí- 
tett gépről pontos másolatot a RIS kiszolgálóra. Az ő segé- 
dei az ugyancsak itt található Imirror.dil és a Setupcl.exe 

0 Rbfg.exe - Távoli rendszerindító floppylemez-készítő 
(Remote Boot Floppy Generator). Azokhoz a hálózati 
kártyákhoz készíthetünk vele indítólemezt, amelyeken 
nincs PXE boot ROM. Erről az előző részben esett szó. 

Oschooser - Ez a könyvtár tartalmazza azokat a fájlokat, ame- 
lyekre a PXE ügyfélnek szüksége van a rendszer és az Ügyfélte- 
lepítő varázsló (Client Installation Wizard, CIW) elindításához és 
futtatásához. Ennek a könyvtárnak legalább két alkönyvtára 
van: 1386 és "olanguage9o, ami megegyezik a kiszolgáló nyel- 
vével, például English. Lássuk először az i386 könyvtárat: 

1386 - Ez a könyvtár a következő fájlokat tartalmazza: 

0 Startrom.com - az első fájl, amit az ügyfél letölt, hogy 
elkezdhesse a rendszerindítást 


0 Ntldr - Végrehajtható állomány, amely a CIW indítását 
végzi (a 9owindir9o Isystem32 Ireminst loschoice.exe kerül 
ide ntldr néven). 

s 


Startrom.F12 - Ugyanazt a funkciót tölti be, mint a 
Startrom.com, csak ez automatikusan ,lenyomja" az F12 
funkciógombot is, így a PXE ügyfél mindig betölti a CIW-t. 
"language" - Ez a könyvtár tartalmazza azokat a képer- 
nyőket, amelyek a CIW "futtatása során megjelennek a fel- 
használónak. Ha testre akarjuk szabni a CIW képernyőit vál- 
lalatunk számára, az itt található fájlokat kell módosítani. 
Setup - Ez a könyvtár tartalmazza a RIS kiszolgálón tárolt 
telepítőkészleteket. Amikor az ügyfél végez a varázslóval és 
elkezdi telepíteni az operációs rendszert, ebből a könyvtár- 
ból másolja a fájlokat. A teljes elérési útvonal a 


VsetuplslanguageslImagesítdirectory names 
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ahol a "odirectory name9o annak a könyvtárnak a neve, 
ahol a telepítőkészlet található, ez esetben a win2000.pro. 
Itt gyakorlatilag megtalálható a teljes i386 könyvtár a te- 
lepítő CD-ről, valamint a templates alkönyvtárban van a SIF 
kiterjesztésű válaszfájl a telepítéshez. Ebből és a varázsló- 
ban megadott adatok alapján fogja a BINL előállítani az 
adott ügyfél telepítéséhez szükséges egyedi válaszfájlt. 
Tmp - Ide kerül a BINL által előbb említett módon össze- 
rakott egyedi válaszfájl. Az állomány neve megegyezik az 
ügyfél GUID-jével SIF kiterjesztéssel. Ez a fájl elvileg addig 
marad itt, amíg a telepítés szöveges módú része véget nem 
ér, de láttam én már karón varjút..... Ennek az a célja, 
hogy ha az ügyfél valamiért újrakezdi a telepítést, akkor az 
rendelkezésre álljanak. Ha nincs folyamatban egyetlen 
RIS-es telepítés sem, és tudjuk hogy mindegyik sikeresen 
befejeződött, és itt mégis találunk fájlokat, azokat nyu- 
godtan letörölhetjük, nincs rá szükségünk. 

A Remotelnstall könyvtárat tartalmazó partíció gyökerén 
létrejön egy SIS Common Store nevű rejtett könyvtár ami 
azokat a fájlokat tartalmazza, amelyek szükségesek a SIS 
működéséhez ezen a köteten. Nézzük mi is ez a SIS! 


Single Instance Storage Groveler 

A RIS által lefoglalt partíción a SIS gondoskodik arról hogy 
minden egyforma állomány ténylegesen csak egyszer fog- 
lalja a helyet a partíción. Ez jól hangzik, milyen jó lenne 
ez egy fájlkiszolgálón ...hhhmm. A SIS használata azonban 
nem támogatott RIS nélkül :-(, pedig a RIS-nek nem kell a 
SIS, és a SIS is működik RIS nélkül. A SIS akkor hasznos 
igazán ha egy RIS kiszolgálón több telepítőkészletet is tá- 
rolunk, hiszen ezek nagy része azonos fájlokból áll, gon- 
doljunk csak az 1386 könyvtár tartalmára! 

A SIS tulajdonképp két szolgáltatásból áll: a SIS szűrőből 
és a SIS Grovelerből vagy gyűjtögetőből. 

A SIS Groveler szolgáltatás feladata a partíció átvizsgálá- 
sa, valamint a duplikált állományok kezelése. A Groveler 
szolgáltatás megjelöli azokat a fájlokat, amelyek azonos- 
nak tűnnek a kötet egy vagy több másik fájljával. Ezután 
alaposabb vizsgálat következik annak megállapítására, 
hogy a fájlok tartalma megegyezik-e. Az ellenőrzés után a 
SIS szűrő átmásolja a fájlt a SIS Common Store könyvtár- 
ba, átnevezi egy egyedi GUID-re és ellátja a .sis kiterjesz- 
téssel. Megjegyzem, hogy csak 32KB-nál nagyobb fájlok 
esetén működik a dolog. Összehasonlításként álljon itt a 
telepítő CD-ről az autochk.exe: 


2121 





General ] Version ] 


ALUTOCHK.EXE 








Type of file: Application 

Description: Auto Check Utility 
Location; E:11386 

Size: 545 KB (558,864 bytes) 
Size on disk: 546 KB (559,104 bytes) 


0 Autochk.exe a telepítő CD-n 
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Majd amikor a Groveler elvégzi a dolgát ez lesz belőle: 


2]ei 


General Iversion] Security ] Summary ] 


JEUTOCHK.EXE 


Application 








Type of file: 

Desciiption: Auto Check Utility 
Location: H:11386 

Size: 545 KB (559.864 bytes) 
Size on disk: . 4.00 KB (4.096 bytes) 


a Egy SIS linké alakult autochk.exe 


Jól látszik hogy maga a link csupán 4.00 KB helyet foglal 
el, valójában a fájl több mint 500 KB. Az eredeti példányt 
a SIS Common Store könyvtár alatt találhatjuk meg, és 
amit a fenti képen látunk az csupán egy link. 


General Iversion] Security ] Summary ] 


ZA d06e1d14-d69e-11d5-9b01-00c0dfe3c3be. sis 











Type of file: SIS File 

Opens with: Unknown application Change... I 
Location: HASIS Common Store 

Size: 545.KB (558.864 bytes) 

Size on disk: 548. KB (551.152 bytes) 


5 A valódi autochk.exe 


A version fül ,tutira" megmondja hogy melyik állomány is 
ez tulajdonképp: 


2121 


File version:  5.0.2164.1 


Description: . Auto Check Utility 


Copyright: Copyright (C) Microsoft Corp. 1981-1999 
Other version information 
Item name: Value: 
Cornpany Name hk.Exe z 






Intemal Name 
Language 


TETTE SES 
a aS5SIS fájl verziója? 


A kötet megegyező fájljai helyén egy hivatkozási pont lesz 
erre a fájlra. Amikor egy program megpróbálja megnyitni 
valamelyik fájlt, a fájlrendszer minden fájl I/O műveletet a 
SIS Common Store könyvtárban levő GUID fájlhoz irányít át. 
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Altupedb 1032KB  EDB Fie 

(E) res2tog 5.120KB Text Document 

(E) rest.log 5.120KB  TextDocument 

aj Masdndex 1KB Fle 

A] Grovelerfie OKB File 

ta grovelini 1KB  Configuraton Settings 
(E) edb00001.log 5.120KB Test Document 

(EJ edb.og 5A20KB Test Document 

5] edb.chk 8KB  RecoveredFie Frag 
A] database mdb 3.080KB  Miciosolt Access Ap. 
2] dü6elea1-dő9e-115-3b01-0000dleZezbe sis 58KB SIS File 

2] dü6etea0-dő9e-11d5-3b01-O0cdfe3e 3be. si 85KB SIS File 

2] d06etegt-d69e-115-9b01-O0c0dfeZedbe. sis 7IKB SIS File 

2] dÜSetege-d69e-11d5-9b01-O0cÜdfeZ3e3be. sír 133KB SIS File 

a] dOGelegd-dő9e-11d5-3b01-O0c0dfe3e3be sis 164KB SIS File 

a] düGetege-d69e-11d5-9501-O0edfeZe be. si 67KB SIS File 

2] d06elegb-d69e-11d5-9b01-O0c0dte2e3be. sír 283KB SIS File 

2] d06eteda-d69e-11d5-9501-O0cdfe3e3be sis 59KB SIS File 


o Így néz ki a SIS Common Store könyvtár belülről 


A linkek és a fájlok összerendelését egy adatbázis tartal- 

mazza. Ismerős a formátum (database.mdb)? 

Érdekes, és valószínűleg soha meg nem válaszolódó kérdés, 

hogy a SIS miért nem az NTFS-ben örök időktől fogva meg- 

lévő Hard Linkekere épít. Mint ismeretes, a Hard Linkek le- 
hetővé tennék, hogy egy fájltartalom több könyvtárbejegy- 
zéssel tartsa a kapcsolatot, így egy fájl látszólag több 
könyvtárban is ott van. A Resource Kit tartalmaz is egy 

POSIX eszközt - In.exe - mellyel képesek vagyunk Hard Lin- 

keket faragni. Ebből következően Redmond is képes erre. 

Valószínűleg a Hard Linkek viszonylagos követhetetlensége 

miatt van ez így. Hamarosan szót ejtünk a SIS kötet men- 

téséről és helyreállításáról: bizony nem mindegy, hogy 
hány példányba kerül szalagra az az adat, amit egyszer már 
egypéldányosítottunk". 

Aki szeret kísérletezni, tegye ezt: 

1. Másolja be a WINNT könyvtárba az ln.exe fájlt a Windows 
2000 Server Resource Kit CD-ről, annak is VNappstposix 
könyvtárából 

2. Szemeljen ki, vagy készítsen egy fájlt, melyen a műtétet 
megejti (mondjuk WINNTUWanmannt.bmp :-) 

3. Adja ki az In lanmannt.bmp linkecske.bmp parancsot 

4. Nyissa meg a linkecske.bmp-t, firkáljon bele, Save 

5. Nyissa meg az eredeti lanmannt.bmp-t. Ott a firka! 


Gyűjtögető életmód 

Amikor a gyűjtögető szolgáltatás hozzákapcsolódik egy kö- 
tethez, alacsony prioritással kezd el futni, így szabályozni 
tudja folyamatait, ha a számítógép terhelése megnő. Ha a 
köteten a szabad hely egy adott érték alá csökken, akkor a 
gyűjtögető CPU használata nő, függetlenül a számítógép 
egyéb terhelésétől. A gyűjtögető intelligens CPU használa- 
tának mellékhatása, hogy indulásakor néhány óráig nem fut 
teljes sebességgel (akkor sem, ha a rendszer tétlen). Ennek 
oka, hogy a szolgáltatás megpróbálja megállapítani, mek- 
kora CPU és I/O sávszélességet használhat anélkül, hogy az 
egyéb rendszerösszetevők működését akadályozná. 

Ha módosítunk vagy felülírunk egy fájlt, ami így már egye- 
di lesz, az új adatok a fájl tényleges helyére, és nem a SIS 
Common Store könyvtárba kerülnek, s a hivatkozási pont is 
megszűnik. A többi fájl hivatkozási pontja a Common Store 
könyvtárra megmarad, akkor is, ha csak egy fájl maradt. 
Vajon milyen alapon feltételezi a SIS Groveler, hogy egy fájl 
megegyezik egy másikkal? Hát úgy, hogy összehasonlítja a 
fájlok aláírásait (signatures). Ezeket az aláírásokat a SIS 
Groveler készíti el - egy előre megadott függvénnyel - min- 
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den egyes fájlhoz, függetlenül attól, hány példányban sze- 
repel a fájl a köteten. Az újonnan hozzáadott fájlok aláírá- 
sának elkészítése után megnézi, hogy azok már szerepel- 
nek-e a SIS Common Store könyvtárban lévő adatbázisában. 
Ha talál olyan fájlokat, melyek aláírása megegyezik, akkor 
azokat bitről bitre összehasonlítja. Ha így is egyeznek, ak- 
kor a fájlokat hivatkozási ponttá alakítja át. 

Ha a Groveler szolgáltatást leállítjuk, vagy a RIS-t leszed- 
jük az Add/Removes Progams-on keresztül, akkor a linkelt 
állományok továbbra is elérhetőek maradnak, új linkek 
azonban nem jönnek létre, ugyanis a SIS szűrő megmarad 
és dolgozik a köteten - az első fomázásig. 

Volt már arról szó, hogy a SIS Groveler a RIS beállítása során 
a kiválasztott partíció egészét az uralma alá vonja, nem csu- 
pán a Remotelnstall könyvtárat. Az ilyen partíciók mentésé- 
hez és visszaállításához használt programoknak ugyan a lin- 
keket nem feltétlenül kell ismerniük, de a reparse címkéket 
igen, enélkül fabatkát sem ér a mentés. Az Ntbackup.exe 
(amely része a Windows 2000-nek) jól kezeli ezeket a fájlokat. 


SIS kötet mentés/helyreállítás 

Amikor egy SIS hivatkozásról biztonsági másolat készül, a 
backup progi felismeri az állomány ún. reparse címkéjéből, 
hogy ez csak egy hivatkozási pont és a SISbkup.dll segítsé- 
gével meghatározza, hogy melyik fájlokat kell a SIS 
Common Store könyvtárból mentenie. A SIS hivatkozást úgy 
menti, ahogy a lemezen szerepel, azaz hivatkozásként és a 
közös könyvtárban levő állományként. Helyreállítás esetén 
az NTBackup felismeri a hivatkozási pontot, majd helyreál- 
lítja a fájlt, ahogy mentette (szintén a sysbkup.dll segítsé- 
gével). Ha a mentéshez használt program nem használja a 
sisbkup.dll-t de ismeri a reparse címkéket, akkor is lehet 
használni a mentéshez és a visszaállításhoz, csak akkor a 
médián az adatok teljes méretükkel fognak szerepelni: ha 
többször megvan ugyanaz a fájl, akkor mindegyik teljes ter- 
jedelmében ott lesz a szalagon. Ebben az esetben visszaál- 
lításnál nem a linkeket, hanem a teljes fájlokat fogja 
visszaállítani az adott backup program. 

Ha a SIS által birtokba vett kötetet helyben mentjük, akkór 
a linkek (úgy, ahogy kell) szintén a szalagra kerülnek. Ha mi 
csak mondjuk a Remotelnstall könytárat és annak teljes 
tartalmát választottuk ki, akkor is ott lesz a szalagon a SIS 
Common Store könyvtár ha azt ki sem választottunk expli- 
cite, és azokat a fájlokat fogja tartalmazni, amelyek a men- 
tésben szereplő SIS linkekhez tartoznak. Az ilyen fájlok 
visszaállításánál a SIS linkek és a hozzá tartozó sis kiter- 
jesztésű fájlok korrekt módon visszakerülnek a helyükre. 
Amennyiben távolról mentjük a Remotelnstall könyvtárat 
(a V- RIS kiszolgálózIReminst megosztáson keresztül), a 
médián a fájlok teljes terjedelmükben fognak szerepelni, 
linkek helyett minden fájl ténylegesen annyiszor lesz ott 
ahány példányban megvan a SIS köteten. Vegyük észre, 
hogy a mentéshez több hely kell a szalagon, mint ameny- 
nyit elfoglalnak a SIS köteten az állományok. Vegyünk egy 
példát: van legalább két telepítőkészletünk egy közönséges 
köteten - ami elfoglal mondjuk 1Gb-ot. Ugyanez SIS köte- 
ten csak kb. 500-600 Mb-ot fog elfoglalni, mert ott a SIS 
Groveler dolgozik, és megszüntet minden duplikátumot. 
Amikor mondjuk távolról mentjük a SIS kötetet, akkor nem 
a linkek lesznek a médián, hanem a tényleges fájlok. Így ne 
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csodálkozzunk, hogy ami a vinyón elfoglalt 500Mb-ot, az a 
szalagon 1Gb-ot követel magának. Az Reminst megosztá- 
son keresztül mentett állományok visszaállításánál nem a 
linkek, hanem a tényleges fájlok kerülnek vissza a kötetre. 


Amikor egy SIS által birtokolt kötetről helyben készített 
mentést vissza akarjuk állítani, fontos hogy a SIS szolgál- 
tatásnak mindenképpen telepítve kell lennie, és át kell 
vizsgálnia a kötetet, mielőtt elkezdődik a helyreállítás. 


Amennyiben ez nem így történik, a SIS linkek által hivat- 


kozott adatokat nem lehet majd elérni, helyette ezt kap- 
juk, mikor kettőt kattintunk egy ilyen fájlon: 


63 FiAtesztáregedit. exe 


The file can not be accessed by the system. 








9 Egy rosszul visszaállított SIS link 


Ha a kötetet ugyanazon a létező RIS kiszolgálón állítjuk hely- 
re, ahol a biztonsági másolatot készítettük (mert mondjuk a 
merevlemezt ki kellett cserélni) , akkor az új merevlemezen lét- 
re kell hozni egy NTFS formátumú kötetet (plusz valamilyen 
meghajtóbetűjellel lássuk el). Ezek után futassuk a risetup 
-check parancsot, ez majd létrehozza a RIS könyvtárszerkeze- 
tet, meg minden egyebet ami a SIS működéséhez kell. Csak 
mindezek után érdemes indítani a SIS kötet visszaállítását! 
Alapjáratban a SIS az egész kötetet felügyeli, azonban 
egyszerű Notepad segítségével ki lehet vonni könyvtárakat 
a SIS felügyelete alól úgy, hogy a SIS Common Store 
könyvtárban levő groveler.ini-be beleírjuk, mit is szeret- 
nénk kihagyni. Valahogy így: 













File Edit Format 
(Disk Info] 
hash read time estimate-2.16806 
compare read time estimate-2. 54709 
mean file size-796406 

read time confidence-0 

volume serial number -276488031 


([Exciluded Paths] 
kutykurutty - Mrtemp 


a Megtiltjuk a SIS-nek a ltemp könyvtár kezelését 
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Mindegy, hogy az egyenlőségjel bal oldalára mit írunk, a lé- 
nyeg, hogy minden egyes könyvtárnak külön bejegyzés kell. 
Ezután csak újra kell indítani a SIS Groveler szolgáltatást, 
és többet nem fogja piszkálni az itt felsorolt könyvtárakat. 


Együttélés a SIS-sel 

A fentiekből - talán - az is következhet, hogy a SIS köteten 
saját adatainkat is tárolhatjuk, hisz a Groveler lebeszélhető 
bizonyos könyvtárak matatásáról. Azonban gondoljunk bele: 
a SIS köteten lévő szabad hely csak látszólagos! Ha azt lát- 
juk, hogy a lemezen - mondjuk - 7 giga hely van, akkor egy 
olyan irányszámot látunk, ami megmutatja, hogy a Groveler 
pillanatnyilag ennyi helyet volt képes szabaddá tenni. 

Ha most nekiállnánk újabb imagek feltelepítésének, a sza- 
bad hely mennyisége átmenetileg leesik, majd a SIS szor- 
goskodása nyomán ismét visszakúszik. Image töltögetés 
után érdemes - akár Performance Monitorral - megfigyel- 
ni! (Ez utóbbi kissé macerás: először ugyanis parancssorból 
engedélyezni kell a Logical Disk objektumot a Diskperf pa- 
ranccsal, Az alábbi ábra egyszerűbb módszert mutat, bár itt 
meg sűrűn kell ütni az F5-öt, hogy lássunk valamit... ) 
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Felsőfokú tanulmányaim során a matek volt az egyik legért- 
hetetlenebb, legunalmasabb tantárgyam. Vizsgára felkészü- 
léskor (amikor egyszerre félévnyi bizonyítást kellett volna el- 
sajátítani) igencsak nehezemre esett elolvasnom a matema- 
tikai regényeket, mert sajnos a beleékelődő képletek zavar- 
ták a folyamatos olvasást. 

Erre tíz évvel később hasonló levezetésekkel fárasztom a 
tisztelt nagyérdeműt. Mivel tudom, hogy viszonylag keve- 
sen matekoznak munkahelyükön, egyszerű képlettel kezd- 
jük, hogy a berozsdásodott fogaskerekek fokozatosan indul- 
hassanak be. De kérlek, ne add fel a harmadik oldalon! Ha 
kell, lapozz vissza, olvasd újra! Ha megemészted az RSA-t, 
soha többé nem fogod ugyanúgy látni a világot. Kitartás! 
Gyermekkoromban minden nyári szünetben több hetet vidé- 
ken, nagyapáméknál töltöttem. Volt ott minden, mit városi 
gyerek csak rajzfilmen vagy kifestőkönyvben lát: háziálla- 
tok, kukoricagóré, lovas kocsi stb. Nagyapám minden évben 
elkápráztatott az alábbi ,matematikai" bravúrral, s én min- 
den évben újra és újra rácsodálkoztam, hogy mik vannak: 


1. számmisztika 

-Gondolj egy számot. (Gondolj egy számot, Kedves Olya- 
sóm!) 

-Adj hozzá hatot. (No mi lesz?) 

-Szorozd meg hárommal. (Megy ez!) 

-Vond ki belőle a gondolt szám háromszorosát. (Ugye még 
ez is megy fejben?) 

-Az eredmény: 18 

Ha kicsit jobban belegondolunk, hamar rájövünk a , trükk" 
nyitjára. 


(Xt6)r 3 - 3X — 3X t 6 r 3 — 3X 
azaz 3X kiesik, marad 3 r 6 — 18 


Engem ezzel a feladvánnyal már húsz éve nem lehet megetetni. 


Rivest, Shamir, Adleman 

Ez a három úr egyike (hármika) annak a néhány kiválasz- 
tott elméleti matematikusnak, akik eredményeiket a gya- 
korlatban is hasznosítani tudták. A többi matematikus 
Csak" bebizonyítja, hogy végtelen számú prímszám van, 
vagy kiszámolja n (pí) értékét négymillió jegyig - egyszó- 
val semmi aprópénzre válthatót nem alkot. 

A mi embereink azonban 1977-ben megalkották a nyílt kul- 
csú titkosítás máig el nem avult, fel nem tört algoritmusát, 
amellyel komplett iparágakat teremtettek. Sőt! Magyaror- 
szágon épp most készül a digitális aláírásról szóló törvény 
- a hármak bandája tehát országokat is mozgat! 

Annyira egyszerű az RSA algoritmus képlete, hogy valószí- 
nűleg a dolog nem is működik. Fogod a titkosítanó doku- 
mentumot, felemeled egy gigantikus hatványra, majd az 
eredmény modulóját veszed... és ezzel látszólag elveszíted 
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algoritmus 


az eredeti dokumentumot. De mégsem, mert ha egy másik 
hatalmas számmal az eredményt ismét meghatványozod, 
majd megint modulóját veszed, visszakapod az eredeti dok- 
sit. Hmmm. De miért? És meddig? Mi az esélye és veszélye 
annak, hogy az RSA-t megtörik? 

E sok kérdésre egyelőre nem adom meg a választ, először 
ugyanis ismét számmisztikázunk. Hatványozni fogunk, így 
számológép használata javasolt! 


2. számmisztika 

- Gondolj egy számot (T). (2 és 10 között, különben kiakad 
a számológéped.) 

- Most keress egy tetszőleges prímszámot (N), mely 
NAGYOBB, mint az előző számod. 

- Emeld a gondolt számot a (N-1). hatványra. 

- Vedd az eredmény modulusát N-nel (modulus - maradé- 
kos osztás) 

- A maradék: 1 

Matekul ez így fest: 


TV mod N - 1 (ha N nagyobb mint T, 
és N prímszám) 


A fenti ,trükk" megfejtéséhez már némileg több beleérzőképes- 
seg kell. De nem túl sok. Ezt a játékot már az ókorban is ismer- 
ték, Euler pedig bebizonyította, hogy a képlet minden prím- 
számmal működik, HA a prímszám nagyobb, mint a gondolt 
szám. Ezek a prímszámok tudnak valamit, amire a többi szám 
nem képes. Vegyük például ezt a másik, hasonló kiszámolót: 


3. számmisztika 

- Gondolj egy számot (T). (2 és 10 között, különben kiakad 
a számológéped. Ne ugyanazt, mint az előbb!) 

- Most keress egy tetszőleges prímszámot (N), mely 
NAGYOBB, mint az előző számod. 

- Emeld a gondolt számot N. hatványra. 

- Vedd az eredmény modulusát N-nel - A maradék: a 
gondolt szám. 


Ez már igen érdekes! Matekul kifejezve: 


T" mod N - T (ha N nagyobb mint T, 
és N prímszám) 


Ez valójában nem más, mint a fentebbi, második számmisztikai 
egyenlet, melynek mindkét oldalát megszoroztuk T-vel. Íme 
előttünk az RSA algoritmus alapja, egy hatványozós, modulós 
képlet, mely visszaadja az eredeti számot! Ez a játék azonban 
egyfelhasználós, az RSA-t viszont párban kell játszani (Titkosító, 
Megfejtő) , másrészt ki engedte meg, hogy egy modulós képlet 
mindkét oldalát büntetlenül megszorozzuk T-vel? Ki mondta, 
hogy igaz marad az egyenlet? Egyelőre zsákutcába jutottunk. 


tech.net! 


Tegyük félre egy pillanatra a játszadozást. Mi is a cél? 


Ariadné, Indiana Jones és a függvények 
Célunk egy olyan függvénypár találása, melyek egymást 
kiegészítve visszavisznek a kiindulóponthoz. Ha a két 
függvény egyikét a Titkosító, másikát a Megfejtő alkalmaz- 
za, ugyanazt az adatot kapjuk vissza. Ilyen függvénypáro- 
kat igen egyszerű találni, mivel gyakorlatilag mindegyik 
ilyen. Legyen a titkosítás például az, hogy a titkosítandó 
számhoz hozzáadunk egyet (hű, de bonyolult!) : 
Adat 4t 1 - Titok 
Ebben az esetben a kiegészítő függvény, mely az eredeti 
adatot visszaadja: 
Titok — 1 - Adat 
Ugyanilyen formán a világ számtalan függvénye használható 
gagyi nyílt kulcsú titkosításra a SIN()-tól a négyzetre emelésig, 
de egytől egyig mind gyatra, mert tulajdonképpen nincs is 
szükségem a fordított függvényre - bőven elég, ha az eredeti 
műveletsorozatot lépésről lépésre visszafelé hajtjuk végre. 
Ariadné függvények, mert húzzák maguk után a fonalat, amely- 
nek segítségével bármilyen bonyolult labirintusból kitalálunk. 
De vegyük csak Indiana Jones példáját. Bemegy egy barlang- 
ba, ahol a háta mögött leomlik a fal, árvíz mossa el a hidakat, 
karók jönnek ki a földből, és ha még ez sem elég, hát meg- 
gyullad valami. Ott áll hősünk a barlang legmélyebb pontján 
bezárva, látszólag reménytelenül (orra előtt a dinkák ősi bál- 
ványszobra) , de ebben a siralmas helyzetben hirtelen megta- 
lálja a kivezető utat ábrázoló térképet. Ha nem Indiana Jones 
kavarodott volna be a barlangba, tutibiztos nem talált volna 
ki, erről tanúskodnak a falak mentén némán üldögélő csontvá- 
zak. (Hollywood nem spórol a dramaturgiai kaptafákkal.) 
Ez kell nekünk! Olyan függvény, melybe ha besétáltunk, 
visszaút nincs többé. Hiába próbálkozunk a lépések fordí- 
tottjával, a mennyezetről lezuhant szikla utunkat állja. Ki- 
jutni csak akkor tudunk, ha a bálvány talpa alól kihúzzuk 
a térképet. Na ez az RSA. Aki nem tudja, hogy a bálvány 
lába alatt van a térkép, az meghal. 
Az ilyen függvényeket csapda (trapdoor) függvényeknek 
nevezzük. Az első működő példával Diffe és Hellmann ruk- 
kolt elő 1976-ban, pontosan a második számmisztikára 
alapozva. Most pedig lássuk, mi kell még: 

1. Moduloaritmetika és kongruencia 

2. Relatív prímek 

3. Euler fíje 

4. A szorzás, mint a helyzet megmentője 


1. Moduloaritmetika, kongruencia 

Ha az a cél, hogy beomoljon az alagút, keresve sem talál- 
hatnánk jobb matematikai műveletet a modulonál. Oly ki- 
válóan fejbecsapja az áldozat számot, hogy az eredményből 
soha nem leszünk képesek visszaállítani az eredetit. A 
modulo, vagy maradékos osztás életünk szerves részét ké- 
pezi. Amikor azt mondjuk, kettőkor kezdődik a NATE, akkor 
valójában 14 óráról beszélünk, modulo 12. Modulo 12-vel 
fejbevágva a 14 tulajdonképpen egyenlő 2-vel. Ezt a furcsa 
egyenlőséget a matematikában kongruenciának hívják, és 


(tech.net 
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hármas egyenlőségjellel jelölik (z). Bármely szám bármely 
másikkal képzett modulusát igen könnyű vizualizálni. A 


127 mod 21 5 1 


nem más, mint egy 21 , órából" álló számkör, melyre a 127- 
et , felcsavarjuk". Többször körbefut, majd a vége valamed- 
dig elér a 21-es számkörön. Ez a maradék a moduló végered- 
ménye. A fenti írásmód a ,hétköznapi". Ugyanez matekul: 
127 z 1 (mod 21) 

Ennek olvasata: a 127 valójában ugyanaz, mint az egy, ha 
modulo 21-ben gondolkozunk. A NATE 2-kor kezdődik ma- 
tekul így fest: 
14 óra z 2 óra (mod 12-ben gondolkodva) 
Hol találunk még modulót mindennapjainkban? Hát a szá- 
mítógépeinkben. A mai elterjedt processzorok 32 bitesek, 
ami tulajdonképpen annyit jelent, hogy 2"32-nel modulál- 
nak minden egész számon végzett matematikai műveletet. 
Ha túl nagy fába vágjuk a fejszénket, a túlcsordulás miatt 
könnyen azon kaphatjuk magunkat, hogy 
1$19g2353416§43 

Hármas egyenlőségjellel persze. De akkor már bánhatjuk. 
Modulo a hét napjai (mod 7), a beszélt nyelv (220V- ket- 
tő-húsz, azaz mod 100) stb. Modulo mindenütt. 

Érdekes, és később hasznunkra válik majd, hogy a modu- 
loaritmetikában (szinte) bármikor fejbecsaphatjuk a műve- 
let tagjait a modulussal, a számítás előtt, vagy a végered- 
ményen - egyre megy. Példa: 

Most 11 óra van. Mennyit mutat majd a vekker 27 óra múlva? 
1. számítás: a modulo a végeredményre sújt le: 

11427 -— 


38 sz 2 (mod 12 esetén) 


2. számítás: a moduloval már a kedzőértékeket fejbecsapjuk 


27 sz 3 (mod 12-vel lecsapva) 
11 5 11 (mod 12-vel lecsapva. Nem változik) 
11 4 3 — 14 Ez 2 (mod 12) 


Ez a trükk ráadásul nemcsak összeadásra, hanem könnyen 
belátható módon gyorsított összeadásra, vagyis szorzásra 
is működik! Egy tyúk levágásának és feldolgozásának ide- 
je 3 óra (forralás, belezés, belsőségek megtisztítása, dara- 
bolás, csomagolás, fagyasztás). Sajnos 50 élő tyúkot kap- 
tunk vidékről bele a panellakás kellős közepébe. Ha dél- 
előtt 11-kor kezdem, vajon fent lesz-e a napocska, amikor 
befejezem? Egyedül csinálom, a feleségem nem ért hozzá 
(nem sokat nyaralt vidéken gyermekkorában). Mivel a na- 
pocska hollétére vagyok kíváncsi, mod 24-gyel dolgozom: 


1. számítás: mod 24 a végeredményre 


3 : 50 5 150 5 
kelőben lesz. 


6 (mod 24) A nap épp 
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2. számítás: mod 24 a kiindulási adatokra 


50 zs 2 (mod 24) 
2 : 3 - 6. A nap épp kelőben lesz. 


Hogy én beledöglök-e a több mint hatnapi megszakítás nél- 
küli tyúkpucolásba? Nem érdekes... Ennél sokkal fontosabb, 
hogy a moduloaritmetika bármikor bevethető. Például, ha egy 
modulós számítás során kezdene elszaladni az eredmény a 
végtelen felé. Csak lesújtunk rá a modulóval, és rögtön nyug- 
ton marad, mi pedig számolhatunk tovább. 


2. Relatív prímek 
Megy még a prímtényezőkre bontás? Hatodik osztályos anyag. És 
hogy kapom meg két szám legnagyobb közös osztóját? Segítek. 


Prímtényezőkre bontás: 


18 223943 
309293: 5 


A legnagyobb közös osztó kiszámítása 

Két szám közös prímtényezőinek szorzata. A fenti esetben 
a 2, és a 3 közös, így 18 és 30 legnagyobb közös osztója 6. 
Ha két szám prímtényezői egyáltalán nem egyeznek, akkor 
a legnagyobb közös osztójuk 1, s a két szám relatív prím 
egymáshoz képest. Példa: 


28 2 1217 
45 2a39395 


Prímtényezőikben nincs közös, legnagyobb közös osztójuk 1. 
A 28 és a 45 egymáshoz képest relatív prímek. Hogy mi a csu- 
dára jó ez nekünk? Hát kipróbálhatjuk, hogy a hatványozós- 
modulós játék (a 3. számmisztika) egészen biztosan csak ak- 
kor működik-e, ha N prím, vagy netalán a relatív prímek is 
eleget ,tudnak", és elég, ha N relatív prím T-hez képest? 

HA a hatványkitevőt fel tudnánk bontani két részre, valahogy így: 
N-P"0 (ami ugyebár addig nem megy, amíg ebben a szám- 
játékban N kötelezően prím) akkor 


T"9 zr (mod N) 


ugyanazt adná, a hatványozást pedig két különböző ember- 
re bízhatnánk 


Titkosító: T" z R (mod N nyomása alatt) 
Megfejtő: R? z T (mod N) 


miénk is lenne az RSA. 


Első próba: 

T-5 (a titkosítandó szám) 

N-6 (relatív prím T-hez, ha nem hiszed, számold ki) 

5" mod 6-...1 
Jaj. Ez nem az eredeti szám, ez biza nem 5. Ez nem jött be. 
Euler! Segíts! 


3. Euler fíje - Mitől működik... 
... a 3. számmisztika? Jobban utánaolvasva kiderül, hogy a 
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hatványkitevő csak prímszámok esetén ugyanaz, mint a mo- 

dulus (N), és ott is csak azért, mert , véletlenül" így jön ki 

minden prímszámnál. A hatványkitevő ugyanis nem más, 
mint a modulus relatív prímjeinek száma -- 1. Ez jó bonyo- 
lultan hangzik, úgyhogy vegyünk példákat: 

"2 9-hez képest relatív prímek (azaz a legnagyobb közös 
osztójuk 1): 1, 2, 4, 5, 7 és 8. Összesen 6 darab. 

"2 7-hez képest relatív prímek: 1,2,3,4,5 és 6. (Azaz minden 
nála kisebb szám, merthogy a 7 maga prím.) Összesen 
megint 6 darab. 

Euler a görög ep (fi) betűvel jelölte azt, hogy egy számnak 

hány relatív prímje van. Így p(9) - 6, és p(7) szintén 6 (bár 

merő véletlenségből annyi, nincs semmi köze a 7-nek a 9- 

hez). Prímszámoknál borzasztó egyszerű kiszámítani: 


p(N) — N-1 


minthogy mindegyik nála kisebb szám relatív prímje egy 
prímnek. A 3. számmisztika kijavítva: 


T "VM zrT (mod N) 
Lássuk az előző példát, hátha így összejön! 


Második próba 
T-5 (a titkosítandó szám) 
N-6 (relatív prím T-hez, 2"3 legnagyobb közös osztója 5- 
tel 1) 
p(6)-1 és 5, azaz összesen 2 darab 
560 mod 6 - ...jaj de izgulok ... — 5! 
Hurrá! visszakaptuk az eredetit! Pedig a matekozáshoz 
használt N nem is prím! Ki meri azt állítani, hogy a 6-os 
prímszám? Elégtelen! 
Ez már majdnem RSA, csak egyfelhasználós. 


RSA! 
Itt buktunk el az előbb: ha a hatványkitevőt fel tudnánk 
bontani két részre, valahogy így: 


0(N)4t1-PrO 
ami most már megy, mert a 6 messze nem prím, akkor 
T"9 z T (mod N után) 


tök jól működne, a hatványozást pedig két különböző em- 
berre bízhatnánk 


Titkos 


ító: T" mod NER 
Megfejtő: 


R? mod NET 
és miénk lenne az RSA. 


Harmadik próba: 
A fenti példában a hatványkitevő 3. Ezt sajna csak így lehet 
szorzótényezőkre bontani: 173. Az 1 nem valami ,jó" hat- 
ványkitevő, ugyanis nem csinál semmit a hatványozás során. 
Már megint kicsúszott a markunk közül ez a nyomorult RSA, 
de nem adjuk fel! 


tech.net! 


4. A szorzás, mint a helyzet megmentője 
A második számmisztika gyúrása 
Emlékeztetőül, ez volt az: 


T"-D z 1 (mod N) 

Most már tudjuk (Euler segített), ez valójában 

T"9 z 1 (mod N-nel kupánvágva) 

Mindkét oldalt emeljük négyzetre: 

TOO x TYAW z ] $ 1 (mod N) 

Most köbre: 

TUD 4 00 a óW c] 4 1 § 1 (mod N) 


Bízvást menne negyedik hatványra is... Írjuk fel a köböst 
a hatványkitevők összevonásával: 


T"9W9 z 1 (ne feledd: mod N!) 


Ebben az a röhej, hogy a moduloaritmetika miatt a hármas 
helyén akármilyen szám állhat, és nem zavarja köreinket! 
Hoppá! Így ha a p(N)--1 felbontása olyan béna lenne, mint 
az előző bekezdésben (1 és 3 jött ki), semmi gond, mert 
K"p(N)--1 éppoly jó felbontási alany, így: 

231 helyett bátran megpróbálkozhatunk akár a 

7"231 (-15) felbontásával: 3 és 5. 

Sokadik nekifutás. 


Negyedik próba 
T-5 (a titkosítandó szám) 
N-6 (relatív prím T-hez, 2"3 legnagyobb közös osztója 
5-tel: 1) 
p(6)-1 és 5, azaz összesen 2 
K"p(N)--1-7"241-15-P"O. P-3, 0-5 
Titkosító: T" mod N-R, azaz 5? mod 6-5 
Megfejtő: R" mod N-T, azaz 5" mod 6-5 
Done!! 
A publikus kulcs P és N 
A privát kulcs A és N 





Egy hétköznapi példa 

A hét napjaival fogunk titkosítani. Az egyszerűség miatt az 
év negyedik napja lesz a titkosítottan átküldött infó, a 
modulus pedig 7, azaz vasárnap. Azért választottam ezt a 
példát, mert ebben oly természetes a modulus! 

T-4, csütörtök (a titkosítandó szám) 

N-7, azaz egy naptárlap napjainak száma (relatív prím T- 
hez, legnagyobb közös osztója 4-gyel: 1) 

p(7)-1, 2, 3, 4, 5 és 6, azaz összesen 6 
K"p(N)--1-4"641-25-P"O. P-5, 0-5 (ez bénaság, a két 
hatványkitevő sose legyen egyforma, de mi csak gyakorlunk) 
A titkosítás valójában a naptár előrepörgetése rengeteg 
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nappal, így rengeteg lappal. Ahol az előrepörgetés megáll, 
megnézzük milyen napot írunk (ez a Mod 7). 

5 Titkosítás: T" mod NER, azaz 4 mod 7-2, azaz kedd. 

Ezt küldöm el a partneremnek. 

-P Megfejtés: R" mod N-T, azaz 2" mod 7-4, azaz csütörtök. 
A publikus kulcs P és N, azaz 5 és 7. Lássuk, ennek birtoká- 
ban vissza tudjuk-e fejteni az eredeti napot. A modulo miatt 
sok vért" veszítettünk, gyakorlatilag fogalmunk sincs, hogy 
hány napot rohantunk előre, kizárólag a maradék maradt. 
Ennélfogva T akármi lehet, mert végtelen sok olyan szám 
van, amit ha P-edik hatványra emelünk, majd mod 7-tel le- 
fejezünk, keddet ad eredményül. Visszaút nincs. Előre pedig 
csak azok hatolhatnak, akik ismerik 0-t, a privát kulcsot. 


Kulcsgenerálás 

Már tudjuk, hogy a modulusnak nem kell prímszámnak len- 

nie, bőven elég, ha relatív prím a titkosítandó adathoz. 

Vajon hogy a csudába biztosítható, hogy a modulus: 

1. Oltári nagy szám legyen 

2. Relatív prím gyakorlatilag bármihez (fontos.doc például) 

3. Meg tudjuk állapítani a p-jét (relatív prímjeinek számát) 

Hmm. Ez igazán nehéz feladatnak tűnne, ha vakon bökdös- 

nénk a számok között. E helyett okosan a következőt tesszük: 

1. Veszünk két bazinagy prímszámot, X és Y 
(www.mersenne.org és egyéb módszerek, lásd BYTE cikkem) 

2. Ezek szorzata lesz N, a modulus, ami ugyan nem prím, 
de mivel két elvetemülten nagy prímszám szorzata, gya- 
korlatilag bármilyen nagy számhoz relatív prím lesz 

3. Mindkét prímszámnak tudjuk a p-jét (prímszámokról lévén 
szó X-1 és Y-1), így N pje is adott: p-(X-1)"(Y-1) 

4. Ezután felbontjuk p--1-et két szám szorzatára (P és 0). Nem 
nehéz, hisz ,K"p(N)--1 éppoly jó felbontási alany", lásd 
fenn. P és 0 ideális esetben egymáshoz képest relatív 
prím, de ez nem szükséges feltétel 

5. A bazinagy prímszámokat elhajítjuk. Többé nem kellenek. 

A kulcspárok pedig (P, N) és (0, N) 


Gyenge pontok 

Az RSA gyenge pontja nem az algoritmus, hanem a kulcs- 
generálás. Mivel N része a publikus kulcsnak, az RSA addig 
él", amíg nincs jobb módszer N prímtényezőkre bontásá- 
hoz, mint a próbálgatás. Az RSA Labs kihívja maga ellen a 
sorsot, és pályázatot hirdet prímtényezőkre bontásra tíz- 
ezertől (576 bites) kétszázezer dolláros (2048 bites) díjért. 
Az [1] címen lehet nevezni! 


Ellenőrzés 

Ne mondd, hogy elsőre feldolgoztad. Nem igaz. Most 
légyszíves olvasd el elölről. Ami nem megy elsőre, majd 
megy másodikra. Ami nem megy másodikra, madj sikerül 
harmadikra. Ami nem megy harmadikra... 


Fóti Marcell 
MZ/X 


A cikkben szereplő URL-ek: 


[11 http://www.rsasecurity.com/rsalabs/challenges/factoring/index.html 
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Biztonságos Windows 2000 DNS szolgáltatás kialakítása 
Az e havi cikk némileg rendhagyó: nem lesz benne ugyanis 
szó az ISA Server-ről. Azért kívánkozik ide mégis ez a téma, 
mert a biztonságos DNS szolgáltatás éppúgy hozzátartozik 
egy jó tűzfalrendszerhez, mint maga a tűzfal. A Windows 
2000 DNS szolgáltatása számos olyan funkciót tartalmaz, me- 
lyek kihasználásával biztonságosabb DNS környezetet építhe- 
tünk. Azt, hogy ezek közül melyeket használjuk ki, a DNS ki- 
szolgáló rendszerben betöltött szerepe határozza meg. 


A DNS kiszolgálók konfigurációja 

Számos módszert alkalmazhatunk a DNS környezet kialakí- 
tásakor. Nyilvánvaló, hogy nincs egyetlen jól bevált recept, 
a rendszer felépítését mindig az adott cég igényei (és per- 
sze pénztárcája határozza meg). 


DNS zárt környezetben 

Ilyenkor a DNS kiszolgálók védett környezetben vannak. Az, 
hogy egyáltalán akarjuk-e magukat a kiszolgálókat bizton- 
ságossá tenni, csak paranoiánk, és az erre fordítható időnk 
határozza meg. Zárt környezetről beszélünk, ami alatt azt 
kell érteni, hogy vagy egyáltalán nincs Internet-kapcsola- 
tunk, vagy a külső router és/vagy tűzfal minden befelé tar- 
tó DNS forgalmat (UDP és TCP port 53) blokkol (mármint azt 
a minimálisat, ami az egyáltalán nem publikált DNS kiszolgá- 
lónkra betévedne) . Ha Active Directorynk is van, ajánlott az 
Active Directory Integrated DNS alkalmazása (egyes ajánlá- 
sok szerint... mások szerint viszont nagyon nem). Egyvala- 
mit viszont mindenképpen célszerű korlátoznunk: a zónák 
letöltését (zone transfer) csak a Name Servers fül alatt fel- 
sorolt kiszolgálóknak engedélyezzük (részletesebben lásd 
később). Megfontolandó az is, hogy az ügyfélgépek csak és 
kizárólag a belső DNS kiszolgálótól kérdezhessenek, az 
Internetről pedig csak a DNS kiszolgáló. Ha ilyen környeze- 
tet építünk, számoljunk azzal, hogy Internetes DNS szolgál- 
tatásunk (ezzel együtt gyakorlatilag az összes nyilvános szol- 
gáltatásunk) valamely Internetszolgáltatóra van bízva. 


DNS Internetes jelenlét esetén 

Ma már szinte nélkülözhetetlen az állandó Internet-kapcso- 
lat. Ilyen kiépítésnél általában két megoldandó feladat vár 
ránk. Egyrészt DNS információkat kell biztosítanunk saját 
szolgáltatásaink eléréséhez (az egész Internetnek), más- 
részt saját ügyfélgépeinknek az Internetről kell DNS infor- 
mációt biztosítanunk. Ilyenkor már célszerű lehet kettévá- 
lasztani a külső DNS szolgáltatást, és a Windows 2000 
domain-hez kapcsolódó DNS-t. 
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Router 





Levelező 
kiszolgáló 
Belső DNS 
Server 


Web- Külső DNS 
kiszolgáló Server 


a DNS Internetes jelenlét esetén 


Az ábrán látható eszközök funkciói: 

Tűzfal 

"0 Minden belső DNS felé irányuló kapcsolatot blokkol 

"Pi Csak a külső DNS 53-as portjáról és portjára menő forgal- 
mat engedélyezi 

Belső DNS kiszolgáló 

2 Windows 2000 

-0 Megtalálható rajta a külső és belső kiszolgálók adatait 
tartalmazó Forward és Reverse Lookup zónák Primary 
vagy Secondary példánya 

0 A dinamikus frissítés engedélyezve van 

Külső DNS Server: 

"0 Bármilyen operációs rendszer 

"0 A dinamikus frissítés tiltva van 

0 Csak külső kiszolgálókra vonatkozó bejegyzéseket tartal- 
mazó Forward és Reverse Lookup zónák találhatók rajta 

Ilyen rendszer esetén a következő biztonsági beállítások ja- 

vasoltak: 

b Az Active Directoryval integrált DNS kiszolgálókat csak 
belső kérések kiszolgálására használjuk. 

"0 A zárt környezetben leírtakhoz hasonlóan (hiszen végül 

is itt a belső kiszolgálóink zárt környezetben vannak) 

csak a Name Servers fül alatt felsorolt kiszolgálóknak 
engedélyezzük a zónák letöltését. 

Tegyük meg ugyanezt a külső kiszolgálókon is. A zónák 

letöltését célszerű minél kevesebb külső kiszolgálónak 

(vagy esetleg egyáltalán nem) engedélyezni. 

Végezzük el a fájlrendszer és a registry biztonsági beállí- 

tásait (lásd később). 

B Mint minden Internetre kihelyezett kiszolgálónál: csak 
a feltétlen szükséges szolgáltatások fussanak a külső 
DNS kiszolgálókon. 

2 Arkülső kiszolgálókon tiltsuk meg a zónák dinamikus fris- 
sítését (Dynamic Updates). 

A kliensek számára Internetes névfeloldást ilyenkor végez- 

het a belső kiszolgáló is, de még jobb, ha a belső kiszolgá- 
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ló(ko)n a külső kiszolgálókat használjuk forwarder-ként. Ha 
viszont a belső DNS kiszolgáló egy Active Directory fa/erdő 
egy részét szolgálja ki, az általa nem feloldható kéréseket 

a felette levő szint DNS kiszolgálójának továbbítja. 


DNS Internetes jelenléttel és reverse lookuppal 
Számos rendszerben szükség lehet arra, hogy ellenőrizzük, 
hogy valaki ,honnan jött". Ezt az ellenőrzést gyakran a 
reverse lookup zónák segítségével végezzük el. E zónák se- 
gítségével nem a nevet oldjuk fel IP címre, hanem éppen 
fordítva (innen származik a reverse lookup elnevezés is). Az 
IP címből feloldott nevet ezután használhatjuk annak el- 
lenőrzésére, hogy valaki például ,.hu" domain-ből nézelő- 
dik nálunk. Ezt a funkcionalitást két módon biztosíthatjuk: 
1. Adjunk hozzá a külső DNS kiszolgálóhoz egy reverse 
lookup zónát, amely tartalmazza az összes Interneten 
megjelenő IP címünket. Az IP címeket társítsuk nevekkel. 
Ezek a nevek lehetnek akár fiktív nevek is, de célszerűbb 
inkább valósakat adni, mivel létezik olyan eset, amikor a 
teljes nevet ellenőrzi a fogadó fél. A DNS kiszolgálókat az 
előzőekben leírtak szerint állítsuk be. A hamis nevek hasz- 
nálata akkor lehet célravezető, ha a belső kliensek legális 
IP címekkel rendelkeznek. Ha hamis neveket adunk meg, 
erősen korlátozzuk a potenciális támadókat a belső háló- 
zat teljes és pontos feltérképezésében. 
Az eszközök funkciói az alábbiak szerint alakulnak: 
Tűzfal 
0 Minden belső DNS felé irányuló kapcsolatot blokkol 
0 Csak a külső DNS 53-as portjáról és portjára menő forgal- 
mat engedélyezi 
Belső DNS kiszolgáló 
0 Windows 2000 
0 Megtalálható rajta a külső és belső kiszolgálók adatait 
tartalmazó Forward és Reverse Lookup zónák Primary 
vagy Secondary példánya 
-0 A dinamikus frissítés engedélyezve van 
Külső DNS kiszolgáló: 
0 Bármilyen operációs rendszer 
0 A dinamikus frissítés tiltva van 
0 Csak külső kiszolgálókra vonatkozó bejegyzéseket tartal- 
mazó Forward és Reverse Lookup zónák találhatók rajta. 
A Reverse Lookup zónában található nevek nem valódiak. 
2. Ha a belső gépeink is legális címekkel rendelkeznek, 
megtehetjük azt is, hogy a külső DNS kiszolgálóhoz hoz- 
záadunk egy reverse lookup zónát, amely a belső hálózat 
másodlagos zónája. A belső kiszolgálón adjuk hozzá a 
Name Servers fül alatt a külső DNS kiszolgálót is, így az ké- 
pes lesz a zóna letöltésére. Állítsuk be úgy a tűzfalat 
és/vagy router-t, hogy a külső és egy belső DNS kiszolgá- 
ló között a zóna átvitele engedélyezve legyen (ha hamis 
neveket szeretnénk megadni, állítsunk üzembe erre a célra 
egy belső DNS kiszolgálót, amely a hamisított reverse zónát 
tartalmazza). A DNS kiszolgálókat itt is az Internetes je- 
lenlétnél leírtaknak megfelelően állítsuk be. Emellett, ha 
hamisított neveket akarunk használni, célszerű az e célt 
szolgáló kiszolgálót csak erre dedikálni, mivel a belső DNS 
kiszolgáló Start of Authority (S0A) bejegyzése megjelenik 
a reverse lookup zónában, vagyis az Interneten is. 
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kiszolgáló 





Belső DNS 
Server 


Belső DC 
DNS-sel 


Web- Külső DNS 
kiszolgáló Server 


a DNS Internetes jelenléttel és másodlagos reverse 
lookup zónával 


Az ábrán látható eszközök funkciói: 

Tűzfal 

"B Minden belső DNS felé irányuló kapcsolatot blokkol 

8 Csak a külső DNS 53-as portjáról és portjára menő forgal- 
mat engedélyezi 

"b Engedélyezi az 53-as porton menő forgalmat a külső és 
belső DNS kiszolgálók között 

Belső DNS kiszolgáló 

2 Windows 2000 

0 Megtalálható rajta a Windows 2000 tartomány Secondary 
Reverse Lookup zónája 

2 Minden más szolgáltatás le van állítva rajta 

Belső tartományvezérlő DNS-el 

-8 Windows 2000 

2 Megtalálhatók rajta a Windows 2000 tartomány Primary 
Forward és Reverse lookup zónái 

2 A dinamikus frissítés engedélyezve van 

Külső DNS kiszolgáló: 

2 Bármilyen operációs rendszer 

-0 A dinamikus frissítés tiltva van 

8 Külső kiszolgálókra vonatkozó bejegyzéseket tartalmazó 
Forward Lookup zóna található rajta 

"2 Van rajta egy Secondary Reverse Lookup zóna, melynek 
információit a belső kiszolgálóról tölti le 


DNS Internetes jelenléttel és belső Forward és Reverse 

Lookup zónákkal 

Ez ugyan nem ajánlott, de szükséges lehet (például abban 

az esetben, ha egy Windows 2000 erdő vagy fa az Interneten 

keresztül van összekapcsolva). Ha a belső DNS bejegyzé- 
seink kikerülnek az Internetre, a külső támadók egyszerű 

DNS lekérdezések segítségével képesek lesznek a belső há- 

lózat teljes feltérképezésére. 

Többféle megoldás létezhet, például: 

2 Használjunk biztonságos VPN csatornákat a domainek 
közti biztonságos zónaátvitelekhez. Ezzel védjük a bel- 
ső DNS bejegyzéseinket az avatatlan külső szemlélő- 
dőktől. A külső kiszolgálókhoz használjuk a fent ismer- 
tetett megoldások valamelyikét. Egy ilyen rendszer lát- 
ható következő ábránkon. Összegezve: ez a megoldás 
jó, mert az összes biztonsági igényt kielégíti. 

"2 Csak azokat a bejegyzéseket adjuk hozzá a külső zónák- 
hoz, melyek feltétlenül szükségesek a hálózat működé- 
séhez. Ez már rosszabb megoldás. Bár a teljes belső 
hálózat valószínűleg nem térképezhető fel teljesen, az 
így közzétett bejegyzések bárki számára elérhetőek. 
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A Állítsuk be úgy a külső DNS kiszolgáló forward és reverse 
lookup zónáit, hogy azok egy belső DNS kiszolgáló má- 
sodlagos zónái legyenek. Ez az a megoldás, ami nem 
megoldás. Ilyen beállításokat még véletlenül se hasz- 
náljunk! (Én is csak elrettentésként írtam ide) 

A fenti megoldások alkalmazásának mindegyike valamekkora 

kockázattal jár. Nyilvánvaló, hogy mindig van kockázat, ha a 

DNS zónáinkat az Internetet használva csereberéljük a tarto- 

mányok között, de ha már így teszünk, törekedjünk a lehető 

legnagyobb biztonságra. Természetesen az elsőként említett 
módszer használata ajánlott. Ráadásul még pénzbe sem kerül. 
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o 3. ábra: DNS Internetes jelenléttel és belső Forward 
és Reverse Lookup zónákkal 


Az ábrán látható eszközök funkciói: 

Tűzfalak 

-? Minden belső DNS felé irányuló kapcsolatot blokkol 

I Csak a külső DNS 53-as portjáról és portjára menő forgal- 
mat engedélyezi 

2 Engedélyezi a routerek közti, titkosított forgalmat 

Routerek 

0 A routerek építik fel a belső DNS kiszolgálók 53-as porton 
folytatott forgalmát védő VPN csatornát 

Belső DNS kiszolgálók 

"2 Windows 2000 

- Megtalálható rajta a külső és belső kiszolgálók adatait 
tartalmazó Forward és Reverse Lookup zónák Primary 
vagy Secondary példánya 

2 A dinamikus frissítés engedélyezve van 

Külső DNS kiszolgálók: 

"0 Bármilyen operációs rendszer 

0 A dinamikus frissítés tiltva van 

"1 Csak külső kiszolgálókra vonatkozó bejegyzéseket tartal- 
mazó Forward és Reverse Lookup zónák találhatók rajta 
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(VI. RÉSZ) 

Ajánlott azoknak a helyeknek a biztonságossá tétele, me- 
lyeket a DNS kiszolgáló a zónainformációk tárolására hasz- 
nál. A zónainformációk vagy az Active Directory-ban, vagy 
a merevlemezen levő fájlokban tárolódnak. 


Áttérés Active Directoryval integrált DNS kiszolgáló 
használatára 

Lehetőségünk van a DNS zóna Active Directoryval integrált 
zónára való átalakítására. Ahhoz, hogy ezt megtehessük, a 
DNS kiszolgálónak Windows 2000 tartományvezérlőn kell 
futnia. Ha a DNS kiszolgáló nem tartományvezérlőn van, ez 
az opció szürke, tehát nem választható (mint ahogy az a kö- 
vetkező ábránkon látszik is). 


Change Zone Type [d 
Select a zone type: 
C éríive Dírectoryíntegraled 


Stores the 20ne data in Active Directogy. 
G [landard primani 

Stores the zone data in a standard text fie. 
C Standard secondary 

Creates a copy of an existing zone. 


tuno 


a Zónatípusok, ha a DNS kiszolgáló nem tartományve- 
zérlőre van telepítve 


Ha viszont a DNS kiszolgáló Windows 2000 tartományvezérlőn 
található, a zónatípusok között megjelenik az Active 
Directory-val integrált zóna. Ez a zónatípus számos előnyt 
nyújt, ezért használata (feltételesen) ajánlott. Ezek közé az 
előnyök közé tartozik például az, hogy a zónainformációk tá- 
rolásának, replikációjának és biztonságos helyen való tárolásá- 
nak gondját az Active Directory leveszi a vállunkról (ha még a 
sört is behozná.. . ). Ha ilyen zónatípust használunk, bekapcsolt 
állapotba kerül az , Only secure updates" opció a dinamikus zó- 
nafrissítésekhez (Dynamic Updates). Ennek a lehetőségnek a 
használata egyébként is javasolt, és DHCP használata esetén 
elég nehezen nélkülözhető a dinamikus frissítés használata. 


A zónafájlok és a registry biztonsága 

Ha a DNS kiszolgáló nem az Active Directory-ban tárolja a 
bejegyzéseket, ajánlott a fájlokat tartalmazó könyvtár biz- 
tonságossá tétele. A javasolt biztonsági beállítások: 
Felhasználói  — Ajánlott 
jogosultságok 
Full Control 


bej ett 





fájl [efa éelő 
A 9oSystemRootJ7oNDNS System 
könyvtár, alkönyvtárai, és 

a benne található fájlok 


Ajánlott az összes DNS kiszolgálón a registry alábbi bizton- 
sági beállításait elvégezni. Ezek a beállítások megakadá- 
lyozzák, hogy a jogosulatlan felhasználók megtudják, vagy 
megváltoztassák a zónafájlok helyét. 






Felhasználói 
csoportok 
HKEY LOCAL MACHINENV Administrator 
System urrentControlSetN System 
ServicesNDNS 


Registery kulcs telle 
jogosultságok 
Full Control 


Full Control 


tech.net! 


BIZTONSÁG 


A zónák letöltésének szabályozása 

A DNS kiszolgálók biztonságossá tételének fontos lépése a 
zónafájlok letöltésének szabályozhatósága. A Windows 
lyozzák a zónák letöltését. Mivel a zónák átvitelekor az 
adott zóna összes bejegyzése átmásolódik egyik kiszolgáló- 
ról a másikra, nagyon fontos, hogy a Windows 2000 tarto- 
mány forward lookup zónáját ne vigyük át olyan kiszolgáló- 
ra, mely nem tagja a tartománynak. Az alábbi képen látha- 
tó a zónaátvitelre vonatkozó négyféle beállítási lehetőség. 


proba.prob Properties KEI 
General ] Start of Authoriy (504) ] Name Servers ] WINS. Zone Transters ] 
4 zone ttansfet sends a copy of the zone to regvesting servers. 
[7 Allaw zone transfers: 
€C Toany server 


C Onlyto servers listed on the Name Servers tab 
6 Onltothe following servers 


IP address: 


EE 


10.1010-10 


To specily secondary servers to be notified of zone updates, cliok 
Motily. 


Not. 





Ok Cancel Apply 


a Zónák átvitelének szabályozása 


A zónaletöltésre vonatkozó négy beállítási lehetőség: 

1. Nem engedélyezzük a zónák letöltését: 

Ez a beállítás megakadályozza a kiszolgálóról a zóna letöltését. 
Természetesen a kiszolgáló ettől függetlenül tölthet le zónákat 
más DNS kiszolgálókról, és a DNS ügyfelek kéréseit is megvála- 
szolja. Nevezhetnénk ezt akár alapbeállításnak is, melyet csak 
akkor változtassunk, ha mindenképpen szükség van rá. 

2. A zóna letöltésének engedélyezése bármely kiszolgálónak: 
Ez a beállítás bármely szabályos zónaletöltési kérésre enge- 
délyezi a DNS zóna letöltését. Bár ez az alapértelmezett 
beállítás, használatát egyik DNS kiszolgálón sem ajánlanám. 

3. A zóna letöltésének megengedése azoknak a DNS kiszolgá- 
lóknak, melyek a Name Servers fül alatt fel vannak sorolva: 
Mivel ez a lista tartalmazza a tartományban található összes 
DNS kiszolgálót, ezt a beállítást arra az esetre javasoljuk, ha 
csak tartományon belüli zónaátvitel szükséges. Például ha 
a DNS kiszolgáló a Windows 2000 Domain zónaadatait tar- 
talmazza, ez az opció lehetővé teszi a tartomány DNS ki- 
szolgálóinak zónaadataik egymással való megosztását. 
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INTERNET SECURITY AND ACCELERATION SERVER (VI. 


RÉSZ) 


proba.prob Properties KE 
General ] Start of Authorty (504). Name Server ] WINS ]) Zone Transfers ] 


To add name servers to the list, cfick Add. 











IP Addiess 
[10.10.10.10] 


Server Name 








tarea ] ént 


0 Ismert DNS kiszolgálók 


4. A zóna letöltésének engedélyezése az IP cím listán sze- 
replő IP címekre.Ez a beállítás a fent említett IP cím lis- 
ta alapján engedélyezi, vagy utasítja vissza a zónák le- 
töltését, vagyis adott, DNS domain-en kívüli kiszolgá- 
lóknak engedélyezhetjük a zónák letöltését. Ez a beállí- 
tás javasolt például abban az esetben, ha a kommuniká- 
ció védett DNS, és olyan kiszolgáló között zajlik, mely 
elérhető az Internetről. Az Active Directory DNS bejegy- 
zéseit tartalmazó zónák Internetről elérhető kiszolgá- 
lókra való átvitele nem javasolt. 


Router és tűzfal beállítások 

A DNS forgalom az 53-as porton (mind UDP, mind TCP) zaj- 
lik. Éppen ezért a tűzfalon és a router-en át kell engedni 
az ezekre a portokra menő forgalmat, hogy a kliensek és 
más kiszolgálók is használhassák a DNS-t. 

Az 53-as UDP portot a kliensek lekérdezései használják, a 
TCP portot pedig zónaátvitelhez. A legtöbb esetben a zó- 
nák kívülről történő letöltése nem megengedett, így ezt a 
portot a szűrést végző eszközökön blokkolni kell. Ha a DNS 
beállításai szerint megengedett a reverse lookup zónák át- 
vitele a külső és a belső DNS kiszolgálók között, akkor a 
belső routert, a tűzfalat és a DMZ-ben található routert 
(persze csak ha vannak ilyenek) ennek megfelelően kell 
beállítani (az 53-as TCP portot át kell engedni, de csak ezek 
között a kiszolgálók közt). Ha bármilyen problémát tapasz- 
talnánk a Windows 2000-rel az 53-as UDP port DNS forga- 
lomra való használatakor, keressük a 0260186 knowledge 
base cikket további információért. 


Hát ennyi fért bele az e havi cikkbe. Minden Kedves Olvasónak 
Kellemes Karácsonyi Ünnepeket és Boldog Új Évet Kívánok! 


BP 
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Nem is hinnénk, hogy napi barangolásaink során mi mindent 
továbbítunk a hálózaton titkosítatlanul, prédaképp, csak 
egy gonosz hackerre várva. Cikkünkben bemutatjuk, hogyan 
készíthetünk titkosított SSL csatornán keresztül működő 
webhelyet a Windows 2000 IIS szolgáltatása segítségével. 


Mi a baj a bejelentkezéssel? 

Egy egyszerű példaalkalmazás segítségével bemutatjuk a 
böngészésben rejlő veszélyeket. Alkalmazásunk egyszerű, 
legyen például egy zártkörű webáruház egyik oldala: a fel- 
használó bejelentkeztetése után elkéri mondjuk a hitelkár- 
tyája számát és a hozzá tartozó PIN-kódot. 





Biztonságos 
weboldalak: 


nttps:// 


www Service Master Properti 





WwebSite ] Performance ] ISAPIFiters ] Home Directory ])  Documents ] 
Directory Secuily HTTPHeaders — ] — CustomErors ] Service] 


Anonymous access and authentication control 


Enable anonymous access and edit the 


authentication methods for this resource. 


CUTE ETT s 
4 7. Anonymous access 
(6 


No user name/passwotd teguired to access this resource. 





Account used for anonymous access: Edit. 


Secure com — Authenlicated accert 


Forthe following authentication methods, user name and password are 
reguired when 
FK - anonymous access is disabled, or 
access is restricted using NTFS access control lists 


F7 Basic authentication (passwordis sent in clear text) 





Select a default domain: Edit... 


[7 Digest authentication for Windows domain servere 




















a  Webalkalmazásunkban a felhasználó bejelentkezés 
után megadhatja a személyes adatait 


Kényes adatokat a kommunikáció során két ízben továbbítunk: 
0 A bejelentkezés során megadott felhasználónév és jelszó 
továbbításakor 
"0 A bejelentkezés után a kérdőív elküldésekor 
Az utóbbi - hacsak valami kliensoldali scriptvarázslattal nem tit- 
kosítjuk - mindenképpen titkosítatlanul halad a hálózaton, a 
bejelentkezéskor szerencsére más a helyzet, az ugyanis függ a 
kiszolgáló és a böngésző által kölcsönösen kiválasztott felhasz- 
nálóazonosítási protokolltól. Az IIS5 által felajánlott protokol- 
lokat webkiszolgáló, webhely, könyvtár, sőt, akár fájlszinten is 
definiálhatjuk, ha az IIS kezelőfelületében megnyitható tulaj- 
donságlapon megkeressük a , Directory Security" oldalt, abban 
pedig az , Anonymous access and authentication control" mező- 
ben az Edit... gombra kattintunk. A lehetőségek a következők: 
8 Anonymous access - névtelen hozzáférés. Az erőforrás 
eléréséhez nincs szükség bejelentkezésre, ezért ilyenkor 
a jelszó nem is utazik a hálózaton. Az ügyfél egy beállít- 
ható felhasználó nevében tevékenykedik (ez alapértelme- 
zésben az IUSR cszámítógépnév:), de ez a párbeszédpa- 
nel felső részén található Edit... gomb segítségével mó- 
dosítható. Ezzel az üzemmóddal minden böngésző kom- 
patíbilis, hiszen használatához nem kell bejelentkezni. 
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a A felhasználóazonosítás módja az IIS-ben beállítható 


A bejelentkezéssel járó protokollok pedig: 

0 Basic authentication - Nyíltjelszavas azonosítás. A felhasz- 
nálónév kódolva, de nem titkosítva utazik a hálózaton 
(erről később). Az üzemmódot a legrégebbi verzióktól 
számítva szinte minden böngésző támogatja. Az 
Edit..." gomb hatására megjelenő dialógusablakban 
azt állíthatjuk be, hogy - ha nem ad meg tartományne- 
vet, - a felhasználót melyik tartományban keressük. 

0 Digest authentication - az IIS5-ben megjelent azonosítá- 
si protokoll, előnye, hogy a hagyományos tűzfalakon 
keresztül is képes bejelentkezni. Bár voltak kezdemé- 
nyezések, egyelőre csak Internet Explorer segítségével 
működik, ráadásul csak Windows 2000 tartományi ki- 
szolgálók és tartománytag ügyfelek között. 

2 Integrated Windows authentication - Windows kiszolgá- 
lók és ügyfelek között (nem feltétlenül csak tartomá- 
nyon belül) használható azonosítási mód. Csak Internet 
Explorerrel működik (akkor viszont akár automatikusan, 
a felhasználó megkérdezése nélkül, az aktuális felhasz- 
nálónévvel/jelszóval is) , viszont nem használható proxy 
tűzfalakon keresztül. (Azaz: leginkább intranetes kör- 
nyezetben ajánlott). 

2 Tanúsítványalapú felhasználóazonosítás - ez nincs az áb- 
rán, mert máshol kell keresnünk, csak a teljesség kedvéért 
soroltuk fel - egy későbbi cikkben ezt is bemutatjuk majd. 

Látható, hogy széles körben - pláne, ha nem csak Internet 

Explorer böngészőket szeretnénk kiszolgálni, - egyedül a 

nyíltjelszavas felhasználóazonosítás tűnik járható útnak. A 

gond csak az, hogyha valaki a példaalkalmazásunk haszná- 

lata során generált hálózati forgalmat Network Monitorral, 
vagy bármilyen más hálózatfigyelő eszközzel meglesi, a kö- 
vetkezőt láthatja: 
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a Nyílt jelszavas bejelentkezés a hálózaton 


Talán olvasható az ábrán a kijelölt sor tartalma: 








HTTP: Authorizatíon 5 


Basic YURLAUSpesRyYXRvejpuYxNzazgyza-- 


A HTTP kérés Authorization fejlécében tehát egy kódolt sor 
utazik, a ,Basic" sor a protokoll típusára utal. De mi tör- 
ténik, ha visszafejtjük a sor Base64 kódolását? 








e command Prompt; 


iicrosoft Windows 2988 IUe 
KC) Copyright 1985-2908 Mi. 









n 5.88.21951 
soft Corp. 








U:N3h64 /d YURtaWSpc3RyYXRucjpuyXNza29yzA sz 
dministrator:password 






AN 


o Basic authentication esetén a felhasználónév és jel- 
szó nem marad titok 


A hálózati forgalom természetesen ugyanígy titkosítatlan 
marad, olvashatóan (még csak nem is kódolva) utaznak a há- 
lózaton a kérdőívbe bepötyögött értékek és persze a kiszol- 
gálótól érkezett válasz is. Még ha a bejelentkezéshez erősebb 
protokollt választunk is (ehhez persze le kell mondanunk az 
alternatív böngészőkről) , a hálózati forgalom továbbra is sza- 
bad préda lesz. Marad a teljes hálózati forgalom titkosítása. 


Webforgalom titkosított csatornán 

Ha a teljes kommunikációt (beleértve már a bejelentkezést 

is) titkosított csatornán bonyolítjuk, két (vagy több) le- 

gyet ütünk egy csapásra: 

"0 Maradhat a nyílt jelszavas felhasználóazonosítás, és vele 
az alternatív böngészők is 

0 Titkosított lesz a teljes forgalom 

0 Adott esetben a proxykiszolgáló nem fog beleszólni a há- 
lózati forgalomba (ez pl. az Exchange 2000 Outlook 
Web Access esetén jöhet jól - ha az OWA nem megy 
proxy mögül http://-n, próbáljuk https://-en) . 

Az SSL csatornán folytatott webes kommunikációt (nevez- 

zük ezentúl HTTPS-nek) gyakorlatilag az összes ma haszná- 

latban lévő böngészőprogram támogatja (ha emlékeim nem 

csalnak, talán a 2.0 verziótól felfelé), úgyhogy a teendőnk 

nem más, mint a webkiszolgáló felkészítése a nagy feladat- 

ra. Ehhez előbb azonban ismerjük meg a HTTPS kommuni- 

káció alapjait! A HTTPS csatorna mőködése során a böngé- 

sző és a kiszolgáló egy közös kulcsú algoritmus segítségé- 

vel titkosítja az adatokat. A kulcs minden alkalommal más 

és más (a kapcsolatfelvétel során jön létre, és csak a csator- 

na bezárásáig , él"). Ezt a kulcsot ,session key"-nek, sza- 

kaszkulcsnak is nevezik, az ábrán kerek fejjel jelöltük. 
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5 Titkosítás közös kulccsal a már felépített HTTPS csa- 
tornán 


Egy dolog azonban megoldatlan: hogyan jut el a közös kulcs 
mindkét félhez? Ehhez a nyílt kulcsú titkosítást vesszük ala- 
pul (azaz olyan titkosítást, ami két, összetartozó kulcsot 
használ: ha az adatot az egyik kulccsal betitkosítjuk, azt csak 
és kizárólag a párjával lehet kinyitni). A webkiszolgáló ren- 
delkezik egy ilyen kulcspárral, aminek egyik tagját közzéte- 
szi (ez a publikus kulcs), a másikat viszont megőrzi magá- 
nak (ez a privát kulcs). Lássuk, mi történik tehát, ha egy 
böngésző egy HTTPS kiszolgálót szeretne elérni: 


gt 
L] 


5 A session key létrehozása nyílt kulcsú módszerrel 


XA 





T 


I 


a 


tést 


7— 


0 A böngésző csatlakozik a kiszolgálóhoz 

0 A kiszolgáló elküldi a böngészőnek a saját publikus 

kulcsát tartalmazó tanúsítványát 

-? 0 A böngésző kitalál egy session key-t 

"8 0 A kitalált szakaszkulcsot a kapott publikus kulccsal 
betitkosítva visszaküldni a kiszolgálónak 

A 0. lépésben utazó csomagot csak és kizárólag az tudja 

kinyitni, aki rendelkezik a titkosításhoz használt publikus 

kulcs privát párjával, az pedig egyedül a webkiszolgáló. 

Miután megkapta a csomagot, kiszedi belőle a szakaszkul- 

csot és máris kezdődhet a kommunikáció! 


ho 


Kulcspár létrehozása és tanúsítvány kérése 

A HTTPS használatához tehát az ügyfélnek nincs szüksége 
tanúsítványra, csak a webkiszolgálónak. A tanúsítvány való- 
disága azonban fontos dolog. Nyílt kulcsú tanúsítványokat 
külön erre szakosodott szervezetek (Certification Authorities, 
CA-k) adnak ki, de a Windows 2000 Server is rendelkezik 
ilyen szolgáltatással. Az ügyfelek számítógépén mindig ta- 
lálható egy lista, amely azon CA-kat tartalmazza, amelyek 
által kiadott tanúsítványokban az ügyfél megbízhat. Ha egy 
olyan tanúsítvány érkezik, amelyet egy ,ismeretlen" CA 
adott ki, a Windows erről figyelmezteti a felhasználót, aki 
eldöntheti, hogy mit szeretne tenni. A hivatalos tanúsít- 
ványkiadóktól származó tanúsítványok pénzbe kerülnek, a 
nemhivatalos (pl. saját kiszolgálónkon futó) tanúsítvány- 
kiadók által kiadottak esetén viszont - ha nem akarunk 
fennakadást -, frissítenünk kell majd a bizalmi CA-k listáját. 
Első lépésként generáljunk a webkiszolgálón egy kulcspárt, 
valamint készítsük el a CA-nak küldendő kérést! Ehhez kat- 
tintsunk az IIS felügyeleti eszközében a webhely tulajdon- 
ságlapjának , Directory Security" oldalán található , Server 
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Certificate" gombra! erre elindul a , Web Server Certificate 
Wizard". A varázslóban haladva válasszuk az új tanúsítvány 
létrehozását (,Create New Certificate"). Ha van a közelben 
elérhető CA szolgáltatás, a varázsló felismeri azt, és felajánl- 
ja a tanúsítvány azonnali, automatikus elkészí(tte)tését. Ha 
nincs, marad az offline mód: , Prepare the reguest now, but 
send it later". Ezután válasszunk egy nevet a tanúsítványnak 
(célszerű a webhely URL-jét választani), majd döntsük el, mi- 
lyen bithosszúságú titkosítást szeretnénk a tanúsítványon. 
Minél hosszabb kulcsot választunk, annál erősebb a titkosítás 
a tanúsítványon (vigyázat! nem a későbbi HTTPS kommuniká- 
cióban!). Írjuk be a szervezetünk, szervezeti egységünk nevét 
(ezek informatív adatok), a Common Name oldalon pedig a 
webhely URL-jét. Az URL pontos megadása fontos, mert ha ez 
nem egyezik a böngészőbe írt címmel, a böngésző riasztani 
ogja a felhasználót. Ezután még meg kell adnunk az orszá- 
got, megyét, várost (ismét csak informatív adatok) , végül pe- 
dig egy fájlnevet, ahova a varázsló a kérést elmentheti. 

LETETEZTETETEETET TEHESSEN 1 -lOl2i 


File Edit Format Help 





7 BEGIN NEW CERTIFICATE REGUEST-———— F" ] 
MIIGJZCCBASCAGAWGYWXITAT BUNVBAMTGHZTOZI"CHIVLMSTÁGFÍYWRTbwIhum51 71] 
[dOEeMBWGALUECXMVUN] YŐHVhbÉBTZWN1 CmUGU2 Vy mVYMROWEGYÜVOGKEWTOZXRB Í 
Y2ZFKZWLPYTERMASGALUEBXMIONYKYXB I C3GXETAPBGNVBAGTCÉJÍZGFWZXNOMOSW 
JEGYDVOGGEWJIVTCCAT IWDOY IKOZIhVCNAGEBBGADGGI PADCCAGOCGGI SAO j eye ! 
[DOADLINCPOhwIPÁLOW6OCGk 2Hg3wRaxTXXGaOSA7XI 7Nek IVxbUJVKIVIxÍnU9MÉ 
[/CAVBJHOFVmZXMherZHAD I CeENZOTZNA Lin T3GTFCNSBMNZSZSCagőwor1/m0ecn 
KT4ABOAZGLULEHEJTSÜBAHDT1XIT SY PVISOSfköxűok jOgUOHT IXÖTYZYCVÍKHNG 
JSzgaanbNaynazwoH7U/4OPOviIz Yew) BROOGYOZKONbYI DÖ DOxO4 ObArvcGDNSGp 
olaángámPSRggZsvnazyhob/ ul 9DpT OgdEGONNORYSZKXINLGFkMTMVOZyaj jus — 
rRgamőywdRor do/3SLj1Z/OSPIRRT wk gZWápSEeJ JB4 UwnLMSOM7K3F Ir27A1/AD 
IZFŐLSM8rcmjooaxTEAngb/CsDINgZNH: S C3MUÉLKVMDUOBpaGpCRNAOTOAD7W7LY 
vt/SbNdcORVXHLULKCSpPB8xaENXSZ72REmw3 51 EgkvGőxM3mrk2AONhtAr9Te/f1 
MuUJÓMEUAMZZUTORRÓOP INYEVKT aY4U3kvin2 JOj SŐBOLFN7OAAxawr 0 ICECIROXS 7 
978/PNFIamrGrGGzf8xkuttVggyvGvd2ygeüSCbwi aMASZOw22ECLONSTS7218xd 

JFTMBOGCI SGAGOBGj CN 
AgÍKDGYKNSZYLÍIXOTUUÍJALÖGOT BOEEAYI 3AGEOMSCWÍTAOBONVHOSBATSEBÁMC 
BPAWEWYDVROT BÁWYCGYI KWYBEGUHAWENYT ÜGC 


Ld 
o Így néz ki egy tanúsítványkérés belülről 





5SpyxOZr xuwr ZOfSYDDVEGEFOGfwő2 SGDUJBPAGMBAAG. 





SGAGGBGÍCNAGI xgedwgesCAGES 





Ha ezzel megvagyunk, keressünk egy tanúsítványkiadót, aki 
a kérésünket teljesíteni fogja. A Windows 2000 tanúsít- 
ványkiadó szolgáltatásának van webes felülete, cikkünkben 
azt fogjuk használni, de a lényeg tulajdonképpen mindig 
az, hogy a kérés tartalmát valamilyen módon eljuttassuk a 
tanúsítványkiadóhoz, ő pedig visszaküldhesse nekünk az el- 
készített tanúsítványt. Most egy Windows 2000 CA-tól fo- 
gunk tanúsítványt kérni. Kövessük a webes varázsló utasí- 
tásait, egészen addig, míg nem kéri a kérés feltöltését. 





EENZTTEYT ETETETT TETT TTZTTTTTT 




















új greet 





a Útban a tanúsítvány felé 


Ekkor illesszük be a kéréskor készült szövegfájlt tartalmát, vá- 
lasszuk ki, hogy webkiszolgálóhoz szükséges tanúsítványt 
szeretnénk, majd haladjunk tovább. Ha minden sikerült, a kö- 
vetkező oldalon már letölthetjük a friss, meleg tanúsítványt. 
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a A kész tanúsítvány 


Ha elkészültünk, már csak telepítenünk kell a tanúsítványt. Eh- 
hez indítsuk el újra a tanúsítványvarázslót az IIS felügyeleti 
eszközében. A varázsló indulásakor felismeri, hogy egy kérés 
már folyamatban van. Kéri, hogy adjuk meg a tanúsítványkia- 
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o A tanúsítvány telepítése után már elérhetők a bizton- 
sági beállítások 


A kiszolgáló beállításai 

Kezdjük a beállítások főoldalánál. Mint az ábrán is látható, 
a tulajdonságlap , Web Site" oldalán elérhető lett az SSL 
Port: mező. A varázsló általában ki is tölti ezt a mezőt (az 
alapértelmezett portcím 443). Van azonban egy fontos do- 
log, amit nem szabad elfelejtenünk: az IIS lehetővé teszi, 
hogy egy IP címen több webkiszolgálót üzemeltessünk. A" 
beérkező kéréseket ilyenkor az ún. Host Header mező értéke 
alapján továbbítja a megfelelő webhely felé. A HTTPS kom- 
munikáció során azonban a Host Header fejléc is titkosítva 
van, és az IIS ezen a szinten még nem tudja azt visszafejte- 
ni. Emiatt a HTTPS kommunikáció mindig az adott IP cím- 
hez tartozó alapértelmezett webhelyre jut (tehát ahhoz a 
webhelyhez, ahol nincs megadva Host Header a konfiguráció- 
ban). Ha egy gépen több webhelyet is szeretnénk elérni 
HTTPS-en keresztül, akkor bizony több IP címre lesz szükség. 
A HTTPS beállítások másik ablaka a tulajdonságlap 
Directory Security oldalán, a Secure Communications mező- 
ben található Edit... gombra kattintva jelenik meg. 

Er 2] 


7. Reguite secure channel (SL. 
TT Reguite 128-bit enciyption 





5 A HTTPS csatorna bekapcsolása 
Ha a Regure secure channel (SSL) opciót bekapcsoljuk (ezt 


megtehetjük nemcsak webhely, de könyvtár, sőt fájlszinten 
is), az adott erőforrás csak HTTPS-en keresztül lesz elérhe- 
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tő. Ha nem kapcsoljuk be, a HTTPS csatorna használata 
nem lesz kötelező (de ettől függetlenül működni fog). A 
Reguire 128-bit encryption a forgalom erősebb titkosítását 
kapcsolja be, de ez csak akkor használható, ha mind a ki- 
szolgálón, mind az ügyfélgépeken telepítve van a High En- 
cryption Pack. A tulajdonságlap többi beállításáról követ- 
kező számunkban lesz szó. 


A puding próbája az evés 

Első lépésben még ne kényszerítsük ki a HTTPS csatornát (azaz 
a fenti ábrán látható ablakba ne tegyünk pipát), csak próbál- 
junk meg HTTPS-en keresztül csatlakozni. Ha a kiszolgáló ta- 
núsítványa nem hivatalos CA-tól származik (és ha a CA nem 
tagja a felhasználó tartományának, akkor ugyanis automatiku- 
san megbízik benne), a következő ablakkal találkozhatunk: 
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Information you exchange with this síte cannot be viewed or 
changed by others. However. there ís a problem with the sites 
security certificate. 








AN The securly certificate was issued by a company you have 
not chosen to trust. View the certificate to determine whether 
ou want tó trust the certiying author. 


The securly cerlíicate date is valid. 


0 Thesecurity certificate has a valid name matching the name 
of the page you are hying to view. 


Doyou want to proceed? 


Ves View Certificate 





a A tanúsítványt ismeretlen szervezet adta ki 


A szolgáltatás ettől függetlenül használható, hiszen ha a 
Yes-re kattintunk, ettől függetlenül felépül a kapcsolat a ki- 
szolgáló felé. Ha ezt a kellemetlenséget szeretnénk elkerül- 
ni, a tanúsítványkiadót (vagy magát a tanúsítványt) fel kell 
venni a megbízott tanúsítványkiadók listájába. Ehhez szük- 
ség van a tanúsítványkiadó saját tanúsítványára (általában 
hozzáférhető a CA weboldalán, vagy más forrásból). Ha ezt 
sikerült megszereznünk, már csak telepítenünk kell. Ehhez 
kattintsunk az Internet Explorer Tools menüjének Internet 
Options parancsára. A megjelenő dialógusablak Content ol- 
dalán kattintsunk a Certificates... gombra, és megjelenik az 
aktuális felhasználó tanúsítványtára. Itt válasszuk a Trusted 
Root Certificates fület, majd az Import... gombra kattintva 
beimportálhatjuk a kapott tanúsítványt. (Tartományi szinten 
mindezt természetesen Group Policy-vel is el lehet intézni). 
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Advanced, ., 


o A tanúsítványkiadók bizalmi listája 


Ha a webkiszolgáló beállításainál kikényszerítjük a HTTPS 
csatorna használatát, a titkosítatlanul érkező ügyfél egy 
hibaüzenettel találja szembe magát: 


File Edt  Wiew  Favorítes  Tosis Help 
$:5. DdA3AlAáaJGOIB 9 eg - eg e ag 


address [ET Map Tfenmeztoro netszaderia netfvsa-a80 


el 
The page must be viewed over a secure 


-lDI 


be 











channel 


The page you are trying to view regvires the use of "https" ín the 
address 


Please try the following: 


9 Try sgsin by typing https:// at the beginning of the address 
104 are attempting to reach, 


HTTP 4034 - Forbi 





SSL regvired 





JJ 


Ej bene 1 1kő imternet 


Hasonló hibaüzenetet kap a felhasználó, ha a HTTPS csa- 
torna használatára képes lenne ugyan, de a kiszolgáló ál- 
tal igényelt 128 bites titkosítást már nem tudja teljesíte- 
ni. A High Encryption Pack a Windows 2000 Service Pack 
2-vel, illetve az Internet Explorer 5.01 SP1 verziójával ke- 
rül fel a számítógépekre. 


Fülöp Miklós 
mick Onetacademia.net 
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DEVELOPER 


Könyvjelzők és tárolt eljárások 

E havi számunkban folytatjuk az előző hónapban megkezdett 
ADO objektummodell ismertetését. Eddig már eljutottunk az 
egyszerű lekérdezések eredményének lekérdezéséig, illetve az 
adatbázis tábláinak megnyitásáig, az adatok módosításáig - 
ebben a hónapban tovább részletezzük a Recordset objektum 
lehetőségeit, és bemutatjuk, hogyan érhetjük el az adatbázis- 
ban tárolt lekérdezéseket, tárolt eljárásokat. A példaprogramok 
az [1], az ADO objektumok referenciája a [2] címen található. 


Recordset megnyitása a Connection objektumon keresztül 
Az előző részben egy mondatban utaltunk arra, hogy Re- 
cordsetet közvetlenül a Connection objektumból is meg le- 
het nyitni. Ehhez a Connection objektum .Execute() metó- 
dusát használhatjuk (connex.asp): 


Set oConn - 
4 Server.CreateObject("ADODB.Connection") 
oConn.Open "File NamezC:Nldblaspsuli.udl" 


Set oRS 5 oConn.Execute("SELECT t FROM Products") 


Az .Execute() metódus mindig csak olvasható, forward- 
only Recordset-et ad vissza, ezért ha ennél többet szeret- 
nénk, a , hagyományos" módszerhez kell folyamodnunk. A 
metódus három paraméterrel rendelkezik, amelyből kettő 
elhagyható (connex2.asp): 


Set oRS 5 oConn.Execute("Products", , 2) 


" 2 - adcmdTrable 


A fenti példa az adatbázisban található Products nevű táb- 
lát nyitja meg, a 2 értékkel jelezzük a providernek, hogy az 
első paraméter egy tábla neve lesz. A connex3.asp egy ki- 
csit összetettebb és előremutató példa: 


oConn.Execute "UpdatePricel", nResults, 4 4t 128 
" 4 - adCmdStoredProc; 128 - adExecuteNoRecords 
Response.Write nResults § " rekord módosult." 

A példaprogram meghívja az adatbázisban található Upda- 
tePrice1 tárolt eljárást (a tárolt eljárások, lekérdezések mű- 
ködéséről részletesebben is lesz szó, most a hangsúly ezek 
meghívásán van) - a harmadik paraméterként átadott 4-es 
érték ezt jelzi a providernek. A 128-as értéket (adExecute- 
NoRecords5) akkor használjuk, ha a parancs futtatásakor nem 
várunk eredménytáblát (például mint most: a tárolt eljárás 
tíz százalékkal megnöveli egyes termékek árait, de mi nem 
vagyunk kíváncsiak magára a listára). Ha nem kérünk ered- 
ménytáblát, akkor a feldolgozás is gyorsabb lesz (természe- 
tesen ilyenkor elmarad a Set oRS - értékadás is). 
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A második paraméterről nem volt még szó: ide egy változót 
adhatunk meg, amibe a provider az eljárás futtatása után 
beírja, hogy az eljárás során hány rekord módosult. Ezt csak 
az úgynevezett , akció" eljárásoknál van értelme használni, 
amikor a végrehajtott parancs adatmódosulással jár. 


Ne felejtsük el, hogy az adatmódosítással járó művele- 
tekhez az aktuális felhasználónak (aki ASP kódok ese- 
tén az anonymous webfelhasználó) az adatbázisra, vagy 
annak érintett részeire írásjoggal kell rendelkeznie! 


Könyvjelzők a Recordsetben 

A könyvjelzők nagyon hasonlítanak a hagyományos könyv- 
jelzőkhöz: egy-egy könyvjelző az aktuális Recordset vala- 
melyik rekordjára mutat. Az aktuális rekordra mutató 
könyvjelzöt a Recordset .Bookmark jellemzőjéből olvashat- 
juk ki. Ennek a jellemzőnek értéket is adhatunk, ilyenkor a 
kurzor a könyvjelzővel jelölt rekordra lép (ha ez lehetséges) . 
A bookmarks.asp bemutatja a könyvjelzők használatát, né- 
hány fontosabb sor a példából: 


Set oRS - Server.CreateObject("ADODB.Recordset") 
aduseClient 
" adcmdTable 


ORS.CursorLocation z 3 ! 


ORS.Open "Products", oConn, , , 2 


vBookmarkl1 - oRS.Bookmark 
ORS.MoveNext 
ORS.MoveNext 
vBookmark2 - oRS.Bookmark 


ORS.Bookmark - vBookmarkl 


"vissza az első könyvjelzőhöz 


Nem minden provider támogatja a könyvjelzőket, sőt, még a 
kurzor típusa és helye is számít (az Access 2000 például csak 
kliensoldali kurzorral képes rá). Fontos, hogy minden könyvjel- 
ző csak abban a Recordsetben érvényes, ahonnan származik, 
az egyszerű könyvjelzők Recordsetek között nem vihetők át. 


Szolgáltatások lekérdezése 

Az, hogy egy adott provider, konkrétabban egy adott 

Recordset képes-e bizonyos dolgokra, egyszerűen lekérdez- 

hetjük a Recordset .Support() metódusával. Az előbbi pél- 

dából kiragadva (bookmarks.asp): 

If Not oRS.Supports( 8192 ) Then " adBookmark 
Response.Write "Ez a Recordset nem támogatja a 

3, Bookmarkok használatát." 

End If 


A metódusnak paraméterként az egyes funkciók azonosítóit 
adjuk át (ha több mindent szeretnénk egyszerre lekérdezni, 


tech.net! 


az értékeket adjuk össze), amire a függvény igaz vagy ha- 
mis értékkel válaszol. Néhány funkció (a teljes lista megte- 


kinthető a [3] címen): 























Konstans [áig Funkció 
adAddNew 0x1000400 Új rekordok létrehozása 
(16778240)  (.AddNew()) 
adApproxPosition . 0x4000 Lapok használata 
(16384) (.AbsolutePosition és 
.AbsolutePage) 
adBookmark 0x2000 Könyvjelzők használata 
(8192) (.Bookmark) 
adDelete 0x1000800 Rekordok törlése 
(16779264)  (.Delete()) 
adFind 0x80000 Keresés 
(524288) (.Find()) 
adMovePrevious 0x200 A kurzor visszafelé 
(512) is mozgatható 
(.MovePrevious()) 
adResync 0x20000 Adatok szinkronizálása 
(131072) (.Resync()) 
adUpdate 0x1008000 A Recordset adatai 
(16809984)  frissíthetők (.Update()) 


A rekordok szűrése 

Ha már van egy Recordsetünk, annak rekordjait tetszés 
szerint szűrhetjük is. Így egyetlen lekérdezés eredményét 
többféle nézetben is felhasználhatjuk, ha a kedvünk éppen 
úgy tartja. A szűréshez a Recordset objektum .Filter jellem- 
zőjének kell egy szöveges feltételt megadni. A feltétel for- 
mátuma hasonlít a SELECT SOL utasítás WHERE után követ- 
kező részéhez (filter.asp) : 


ORS.Filter 5 "UnitPrice € 30 AND 
H, ProductName LIKE "$ch$"" 


A feltételben a mezőnevet egy műveleti jel, majd azt egy 
érték követi, az egyes feltételek között használhatók az 
AND (és) és az OR (vagy) operátorok és persze a zárójelek 
is. A műveleti jel lehet c, 5, cz, 5—, cs, -, vagy LIKE; ez 
utóbbinál egy szöveges értéket kell megadnunk, amiben 
használhatjuk a " vagy a 99 joker karaktereket. A dátumér- 
téket H jelek közé írva adhatjuk meg. (A példa a harminc- 
nál olcsóbb olyan termékekre vonatkozik, amelyek neve tar- 
talmazza a , ch" karaktersorozatot. ) A szűrést kikapcsolhat- 
juk, ha a .Filter jellemző értékének üres stringet adunk 
meg, vagy ha az adFilterNone konstant (értéke 0) használ- 
juk. Az alábbi sorok bármelyike kikapcsolja tehát a szűrést: 


oRS.Filter — "" 


ORS.Filter 0 " adFilterNone 


A .Filter jellemző értékeként nemcsak szöveges értéket, 
hanem - mint láthattuk - konstanst is átadhatunk. A hasz- 
nálható konstansokat és értéküket lásd a [4] címen. Vé- 
gül: a jellemző értékének átadhatunk előzőleg feltöltött 
könyvjelzőkből álló füzért is: 


ORS.Filter - Array( vBookmarkl, vBookmark2, 


4 vBookmark3) " Előzőleg definiált könyvjelzők 
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Keresés 

A szűrés mellett kereshetünk is a Recordset-ben, ehhez a 

.Find() metódust használhatjuk. A metódus négy paramé- 

tere a következő: 

"B Feltétel - a szűrésben használatoshoz hasonló feltétel, 
de itt csak egy mezőt ellenőrizhetünk 

0 Átugrandó sorok száma - számérték, amely azt jelzi, hogy 
a keresést az aktuális, vagy indulóként beállított pozí- 
ciótól számított hányadik sornál kell kezdeni, ha nem 
adjuk meg, értéke 0 

"I A keresés iránya - kereshetünk a Recordsetben előre 
(adSearchForward (1), alapértelmezés), vagy vissza fe- 
le (AdSearchBackward (-1)) 

"0 A keresés kezdőpontja - itt egy könyvjelzőt adhatunk 
meg; ekkor a keresés a könyvjelző által mutatott re- 
kordtól kezdődik. 

Ha a keresés sikeres volt, a kurzor a talált rekordra áll. Ha 

a keresés nem eredményezett találatot, akkor a keresés 

irányától függően az .EOF vagy .BOF jellemző értéke igaz 

lesz (azaz a kurzor ,, lefut" a Recordset-ről) . 


Logikai lapok használata 

A Recordseteket logikailag lapokra bonthatjuk (persze csak 
azokat, amelyek ezt támogatják). A lapokra bontás tulaj- 
donképpen nem jelent semmi lényeges változást, 
mindössze a Recordsetben található adatok feldolgozását 
könnyíti meg (főleg webes környezetben, amikor nem listáz- 
hatjuk ki a felhasználónak a Recordset teljes tartalmát). A 
logikai lapok méretét a Recordset objektum .PageSize jel- 
lemzője adja meg, alapértelmezése 10. A kurzort továbbra 
is a megszokott módon mozgathatjuk, annak kezelésénél 
nem kell a lapokat figyelembe venni, azonban az .Absolu- 
tePage jellemző értéke mindig azt adja vissza, hogy a kur- 
zor által mutatott rekord hányadik lapon található 
(megintcsak logikailag). Ha az .AbsolutePage értékét mó- 
dosítjuk, a kurzor a beállított oldal első rekordjára áll. (Az 
oldalak számozása 1-től kezdődik.) A .PageCount jellemző 
értéke pedig azt jelzi, hogy összesen hány logikai lap ta- 
lálható a Recordsetben. Végül: az .AbsolutePosition értéke 
mutatja, hogy az aktuális rekord hányadik helyen áll a 
Recordsetben (függetlenül a lapok méretétől és számától) . 
Kicsit sűrű volt? Próbáljuk ki (rspages.asp)! 
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File Bár 





celt 








Termélklista 


Ez a lista 6 oldalból áll, oldalanként 15 rekord. 





o Arterméklista, oldalakra bontva 
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A teljes kódot hosszúsága miatt itt nem mutatjuk meg, de a 
letölthető változatot gazdagon elláttuk megjegyzésekkel. A 
lényeg, hogy a Recordsetet csak a legelső látogatáskor hoz- 
zuk létre, és tároljuk azt a felhasználó Session objektumában. 
Ezután minden egyes látogatáskor a már meglévő Recordsetet 
vesszük elő; abból mindig csak .PageSize darab rekordot lis- 
tázunk. Végül, az oldal alján található navigációs sor segítsé- 
gével lehetővé tesszük a közvetlen mozgást az oldalak között 
(ha a kód ilyen hivatkozást kap, automatikusan az adott oldal- 
ra lépteti a Recordsetet) . A lapok használatához azonban erre 
nincs feltétlenül szükség, maga a kurzormozgatás is elég (mi 
sem bizonyítja ezt jobban, minthogy az oldal egyszerű frissítge- 
tésével végiglépkedhetünk az oldalakon — hiszen a kurzor a lis- 
tázás során mindig előre lép egy-egy oldalnyit). 


Tárolt eljárások 

Az adatbáziskezelők (még az Access is) általában jóval töb- 
bet tudnak, mint táblák megnyitását, módosítását, ,ad hoc" 
parancsok, lekérdezések futtatását. A tárolt eljárások (Access 
esetén tárolt lekérdezéseknek nevezik) általában összetettebb, 
bonyolultabb feladatok végrehajtására is képesek, ráadásul 
lényegesen gyorsabbak, mintha ugyanaz(oka)t a műve- 
let(ek)et egyenként, , kívülről" hajtanánk végre. A komo- 
lyabb adatbáziskezelők előre felkészülnek a létező tárolt el- 
járások használatára, futtatási terveket készítenek, esetleg 
gyorsítótárban megőrzik az eredményeket. Mindemellett a 
tárolt eljárások használata lényegesen kényelmesebb is, hi- 
szen egy tetszőleges bonyolultságú folyamat elindítása ré- 
szünkről egyetlen eljárás meghívásában merül ki. 

A példák során az aspsuli.mdb tárolt lekérdezéseit fogjuk 
kezelni, de a módszer hasonló lenne akkor is, ha mondjuk 
SOL Servert használnák. 
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a Egy összetettebb lekérdezés az Access-ben 


A fenti ábrán látható lekérdezés (OrderCategoriesByEmploye- 
es) eredménye egy táblázat, amelyben az alkalmazottanként 
és árukategóriánként eladott termékek darabszáma szerepel. 
A lekérdezést meghívni azonban semmivel sem nehezebb, 
mint egy egyszerű táblát megnyitni (guery1.asp): 


Set ORS - Server.CreateObject("ADODB.Recordset") 
OoORS.Open "OrderCategoriesByEmployees" , 


4 oConn, , , 4 "adCmdStoredProc 


While Not OoRS.EOF 

Response.Write OoRS("EmpName") §£ " / " 
Response.Write ORS("CategoryName") a " —" 
Response.Write oRS("Orders") § "CcBR2" 
ORS.MoveNext 


WEnd 
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Az egyetlen különbség, hogy a Recordset megnyitásakor az 
utolsó paraméterben jelezzük, hogy a célpont most egy tá- 
rolt eljárás (adCmdStoredProc). A lekérdezés egy táblát ad 
vissza, a tábla mezőinek nevét pedig maga a lekérdezés de- 
finiálja (innen az EmpName vagy az Orders mezőnév). 

Az eljárást most a Recordseten keresztül nyitottuk meg, de 
van rá más, közvetlenebb és egyben rugalmasabb mód is, ez 
pedig a Command objektum használata. A Command objek- 
tum kifejezetten arra készült, hogy egy SOL parancsot, vagy 
tárolt eljárást jelképezzen és futtasson. Lássuk a fenti pél- 
dát a Command objektummal megvalósítva (guery2.asp): 


Set oCmd 5 Server.CreateObject( "ADODB. Command" ) 
oCmd.ActiveConnection - oConn 

oCmd.CommandText - "OrderCategoriesByEmployees" 
oCmd.CommandType - 4 " adCmdStoredProc 


Set OoRS - oCmd.Execute 


Első lépésként létrehozzuk az objektumot, majd az .ActiveCon- 
nection jellemzőnek átadjuk a korábban már megnyitott 
Connection objektumot. Ezután a .CommandText jellemző beállí- 
tása következik (ez is lehet SOL parancs, tábla vagy eljárás neve) , 
majd a .CommandType paraméter - szokás szerint - jelzi, hogy a 
parancs milyen típusú. Ha ezeket a paramétereket beállítottuk, 
nincs más hátra, mint meghívni az .Execute() metódust, ami 
egyébként pontosan ugyanazokat a paramétereket várja, amelye- 
ket a Connection objektum .Execute() metódusánál átadhattunk. 
Ha megnézzük, hogy a guery2.asp Command objektuma mi- 
lyen Recordset-et adott vissza, láthatjuk, hogy kiszolgáló- 
oldali, forward-only, csak olvasható kurzort kaptunk. Ez 
nem feltétlenül használható minden esetben - akkor vi- 
szont mire jó a Command objektum? 


Command objektum, mint a Recordset forrása 

Mit tehetünk tehát akkor, ha saját szánk íze szerint akarjuk 
formálni a Recordset típusát, de ugyanakkor nem akarunk 
lemondani a Command objektum - igazán csak később is- 
mertetett - előnyeiről? Nos szerencsére a Recordset adat- 
forrása, a .Source jellemző nemcsak szöveges értéket, ha- 
nem egy előkészített Command objektumra vonatkozó hi- 
vatkozást is elfogad. Ugyanez igaz a Recordset objektum 
.Open() metódusának első paraméterére is (guery3.asp). 

A példában először létrehozzuk a Connection, majd a 
Command objektumot. A Command objektumban beállítjuk 
a parancs adatait, valamint az aktív adatbáziskapcsolatot a 
.ActiveConnection jellemző segítségével (ha a Recordset ob- 
jektum forrásának Command objektumot adunk meg, az .Ac- 
tiveConnection jellemzőt mindig csak a Command objektum- 
nál kell kitölteni). Miután ez megvan, létrehozunk egy új 
Recordset objektumot, beállítjuk a kurzorjellemzőket és a 
zárolási stratégiát, majd beállítjuk a forrást (ne felejtsük el 
a Set parancsot, hiszen objektumreferenciával dolgozunk!) . 
Ezután már csak az .Open() metódus meghívása marad, és 
máris megy minden, mint a karikacsapás! 


rAkció"-lekérdezés 

Korábban már említettük, hogy akció-lekérdezésnek nevez- 
zük az olyan parancsokat, tárolt eljárásokat, amelyek nem 
adnak vissza eredménytáblát, csak csendben elvégeznek 
egy adott feladatot (esetleg azt tudhatjuk, hogy hány rekord 
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esett , áldozatul" a műveletnek, de semmi több). A példa- 
adatbázisban található UpdatePrice1 lekérdezés az 1-es 
már bemutattuk). Most lássuk, hogyan hívhatjuk meg 
ugyanezt a tárolt lekérdezést a Command objektum segít- 
ségével (guery4.asp): 

Set oCmd - Server.CreateObject("ADODB.Command") 
oCmd.ActiveConnection 5 oConn 
oCmd.CommandText - "UpdatePricel" 
oCmd.Execute nResults, , 4 4 128 

"adcmdStoredProc t adExecuteNoRecords 
Response.Write nResults § " rekord módosult." 


Paraméterezett lekérdezések 


A fenti tárolt lekérdezés mindig egy adott termékcsoport 
árait növeli, egy adott százalékkal. Az tárolt eljárásoknak, 
lekérdezéseknek azonban bemenő paramétereket is adha- 
tunk, amelyeket az eljáráson belül felhasználhatunk. Így 
készült a példaadatbázis UpdatePrice2 lekérdezése: 












































a Paraméterezett lekérdezés 


A lekérdezés két paramétert vár, az egyik a kategória azono- 

sítója, a másik pedig a százalékérték. A kérdés már csak az, 

hogy hogyan adhatjuk át a paramétereket a tárolt eljárásnak? 

A válasz az objektummodellben rejlik: a Command objektum- 

hoz csatolt Parameter objektumokkal. Ezeket a Command ob- 

jektum Parameters kollekciója tartalmazza, a kollekció a kö- 

vetkező jellemzőket és metódusokat tartalmazza: 

0 .Count: a paraméterek száma 

0 .Item: egy adott paraméter 

0 .Append(): paraméter hozzáadása 

0 .Delete(): paraméter törlése 

A .Refresh(): paraméterek frissítése 

Az egyes paraméterek jellemzője a következő 

0 Név: a paraméter neve, ezzel hivatkozunk rá 

0 Típus: adattípus, az adattípus-konstansok értékét lásd 
az [5] címen 

0 Irány: egy paraméter lehet bemenő (Input), kimenő (Out- 
put), illetve visszatérési érték (Return Value), ez álta- 
lában magán a tárolt eljáráson múlik. A paraméter irá- 
nyát az alábbi táblázatban szereplő konstansok segít- 
ségével határozhatjuk meg: 


neg enő Érték Típus 














adParamInput ű Bemenő (alapértelmezett) 
adParamInputOutput 3 Bemenő és kimenő 
adParamOutput 2 Kimenő 
adParamReturnValue 4 Visszatérési érték 
adParamUnknown 0 Ismeretlen irány 
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A Command objektum Parameters kollekciójához az objek- 
tum .CreateParameter() metódusával előzőleg létrehozott 
Parameter objektumokat adjuk hozzá. A .CreateParame- 
ter() metódus paraméterei az alábbiak: 

8 Name: a paraméter neve 

Type: a paraméter típusa 

Direction: a paraméter iránya 

Size: a paraméterváltozó mérete (a típusból adódik, nem 
kötelező megadni) 

Value: a paraméter értéke (később is megadható). 

Az így létrehozott paraméterobjektumot átadjuk a 
Parameters kollekció .Append() metódusának. A paramé- 
tert ezután a Parameters kollekció .Item jellemzője segít- 
ségével érhetjük el (név szerint). 

A fenti példában szereplő lekérdezés két paraméterét tehát 
így címezhetjük meg (paramg.asp): 


ddd 
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Set oCmd - Server.CreateObject("ADODB. Command" ) 
oCmd.ActiveConnection - oConn 

oCmd.CommandText - "UpdatePrice2" 

:" Paraméterobjektumok létrehozása 

Set oParam - oCmd.CreateParameter("CatID", 3, 1) 
oCmd.Parameters.Append oParam 

Set oParam - oCmd.CreateParameter("Percent", 3, 1) 
oCmd.Parameters.Append oParam 

" Értékadás 

oCmd.Parameters.Item("CatID") 5 

4 cInt(Reguest( "category" )) 
oCmd.Parameters.Item("Percent") 5 


4 cInt(Reguest("percent")) 


A Parameters kollekció frissítése 

Ha a provider azt támogatja, nem kell magunknak létrehoz- 
ni a paraméterobjektumokat. Elég, ha a Command objek- 
tumnak beállítjuk, hogy mely tárolt eljárást szeretnénk meg- 
hívni, majd meghívjuk a Parameters objektum .Refresh() 
metódusát. Ez feltölti a Parameters objektumot a megfelelő 
paraméterekkel. Ezt a szolgáltatást az Access providere saj- 
nos nem támogatja, de a listparams.asp példaprogramot ki- 
próbálhatjuk, ha van egy SOL Server a közelben. 


Fülöp Miklós 
mick Onetacademia.net 


[date HETZA Ag L TT E 

[1] http://technet.netacademia.net/download/asp/11 
[21 http://msdn.microsoft.com/library/ 
en-us/ado270/htm/mdmscadoobjects.asp 

[3] http://msdn.microsoft.com/library/ 
en-us/ado270/htm/mdcstcursoroptionenum.asp 

[4] http://msdn.microsoft.com/library/ 
en-us/ado270/htm/mdcstfiltergroupenum.asp 

[51 http://msdn.microsoft.com/library/ 
en-us/ado270/htm/mdcstdatatypeenum.asp.— 7" 


A MICROSOFT MAGYARORSZÁG SZAKMAI MAGAZINJA 


2001. 12. 6 


35 


DEVELOPER 


A Ouery 


Talán már Magyarországon is lassan elérkezik a Clipper 
Summer "87 alapú alkalmazások hanyatlása, és előbb-utóbb 
minden adatbázis oda kerül, ahova való: valódi adatbázis- 
motoros, SOL alapú kiszolgálóra. Az átállás fájdalommal jár: 
egyszerre , vész el" a megszokott .DBF formátum, a szép DOS- 
os, karakteres alkalmazás és a szekvenciális fájlkezelés lehe- 
tősége. Ekkora traumát nehéz komoly lelki sérülés nélkül el- 
viselni, s ennek tetejébe jön még a COM és az ADO (ActiveX 
Database Objects, lásd ASP Sulinkat). Nem csoda, ha sok 
programozó örül, ha az alap SOL utasítást összeeszkábálja... 


SELECT $ FROM VEVOK 


...és felkínlódja egy VisBas formra. Semmi filter, egyszerűbb 
végigszaladni a rekordokon, és csak a kívánatos elemeket be- 
lepakolni abba az átkozott kombó boxba. Huh. Ezzel megvol- 
nánk. Az alkalmazás elindul. Ám érthetetlen okokból fokoza- 
tosan és folyamatosan lassul. Fél évvel az átadás után már 
több, mint 11 másodpercbe telik az egykor oly fürge űrlap 
megjelenése. Pár hét múlva 15 másodperc. Itt tenni kell va- 
lamit! Vajon mi hiányzik? Nyilván egy index. Valahogy meg 
kellene adni a lekérdezésben, mint anno a Clipperben. Az 
hogy vágtatott ehhez a vacak SOL Serverhez képest! Egy hét 
alatt kiókumláljuk, hogy így kell odaírni neki... 


SELECT $ FROM VEVOK (IndexzVevoldindex) 


...éS ezzel elkövettünk mindent annak érdekében, hogy ez az 
alkalmazás a büdös életben ne futhasson optimális teljesít- 
ménnyel. Nem elég, hogy egy korlátozás nélküli (unrestricted) 
lekérdezést adtunk neki (melynek elvégzéséhez egyszerűen 
nem kell index), hanem még ráerőszakoltunk egy alkalmatlan 
indeket is. Még jó, ha clustered, akkor legalább nem biztos, 
hogy lassít. De ha ne adj" Isten nonclustered, az eredeti 15 
másodperc felfut 243-re. Hinnye. Mi van itt?? Vagy inkább ki? 
coffe 

Elnézést kérek a guruktól, akik szerint ilyen nincs. Hát én 
éppen két hónapja (Krisztus után 2001, október havában) 
menekültem el sikoltozva egy hasonló szörmedvény láttán. 
Szakérteni híttak, mert az a , tetves" SOL Server állandóan 
eldobálta a kapcsolatokat. Mondom nekik telefonba: dead- 
lock. Nem értik. Na jó, odamegyek. Életem egyik legször- 
nyűbb optimizer hintekkel telehajigált alkalmazásához volt 
szerencsém. A programozó írt egy szekérderéknyi tárolt el- 
járást (gondolom, hogy gyorsabb legyen az app), de egytől 
egyig mindet tönkretette bevarrott optimizer hintekkel. Ak- 
kor fogtam menekülőre a dolgot, amikor ezt megláttam: 


SELECT $ FROM VEVOK (Index-0) 
WHERE Name- "Kovács" 
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Itten paradigmaváltásra lenne szüség. Ebben a hazában. 
Jogosítvány nélkül nem vezethetsz, de elemi ismeretek nél- 
kül, pusztán egy halom babonával felfegyverkezve jó pén- 
zért programozhatsz. Piha! 


off 


Mér? Mi a baj? 

Hát, eddig minden hibás, amit összegyűjtöttem: 

1. A SELECT " FROM VEVOK lekérdezés visszaadja a tábla 
összes sorát és összes oszlopát, ergo indexet használni me- 
rőben felesleges. Akinek az egész tábla kell, annak az egész 
kell, punktum. 

2. A SELECT " FROM VEVOK (IndexzVevoldindex) egy in- 
dexszel jottányit sem gyorsítható lekérdezésre ráerőszakol 
egy indexet. Ha ez nonclustered, a futási idő több százszo- 
rosára nőhet! Mindezt úgy, hogy az SOL Server tudván tud- 
ja, hogy butaságot kérünk tőle. 

3. A SELECT " FROM VEVOK (Index-0) WHERE Name- Kovács" 
sziporka pedig azt mondja az SOL Servernek, hogy még ha 
lenne is jó index, akkor se használja! 

A legfőbb baj, minden teljesítményprobléma okozója azon- 
ban az a programozó, aki nem tudja, hogy egy nálánál in- 
telligensebb teremtménnyel kommunikál, amikor SOL lekér- 
dezéseket ír. Ő a Ouery Optimizer, akinek az a feladata, 
hogy a felhasználói lekérdezéseket a lehető legrövidebb idő 
alatt hajtsa végre. Kiváló munkát végez! Hagyjuk dolgozni! 


Az optimalizálás menete 

Valahányszor az SOL Server lekérdezésfuttatója új SOL pa- 
rancsot kap - kevés kivételtől eltekintve - ugyanazon a lé- 
péssorozaton megy végig, mire futtatásra kerülne a sor: 


nya 


act 
5 Az SOL lekérdezések feldolgozásának menete 


1. Szintaktikai ellenőrzés. Ebben a lépésben az dől el, 
hogy a parancs megfelel-e a Transact SOL nyelv szintakti- 
kájának. Hogy SELECT után egy értéket produkáló kifejezés 
van-e, EXEC után tárolt eljárás stb. Ha ezen a teszten átcsú- 
szik a lekérdezés, jöhet a következő lépés: 

2. Objektumhivatkozások feloldása. Vajon léteznek-e a hi- 
vatkozott táblák és mezők és függvények és változók és ...? 
Ha igen, ez a lépés összegyűjti az idevágó metaadatokat is 
(mezők típusa stb.) Amint ez megvolt, következhet a tuning: 
3. Optimalizálás. Ebben a fázisban többek között a hivatko- 
zott táblák összekapcsolása (dzsoin) és a megfelelő indexek 
kiválasztása történik meg. (Hangsúlyozom: a megfelelő!!!) 
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Ennek a lépésnek az eredménye az úgynevezett Ouery Plan, 
vagy végrehajtási terv, ami elmenthető a procedúra gyorsí- 
tótárba (kess). Ezután jön a: 

4. Fordítás. Pszeudokódra, mert az hordozható. Az SOL 
Servernek ugyanis nemcsak Inteles verziója van. Végül a 
pszeudót is fel kell dolgozni, ez lesz az utolsó lépés: 

5. Futtatás. Fuss Forrest, Fuss! 

Jelen dolgozat szempontjából a harmadik lépés a legfon- 
tosabb, feltételezzük, hogy létező objektumokra hivatkozó 
szintaxhelyes SOL utasításokat bárki képes készíteni. Elő- 
ször foglalkozzunk a ,jó index" szindrómával. Ehhez ismer- 
nünk kell a Ouery Optimizer észjárását: vajon mi alapján 
dönti el, hogy hogyan érdemes lefuttatni egy lekérdezést? 
Költségalapon! Több végrehajtási módszert (indexszel, 
anélkül stb.) is mérlegel, majd ezek közül a legolcsóbbat 
választja. Már csak a ,pénznemet" kell elárulnom: fizikai 
I/0. Amelyik lekérdezési stratégia a legkevesebb lemezrán- 
gatással jár, az a legolcsóbb, hisz az egész számítógép leg- 
lassabb eszköze mind a mai napig a mechanikus, forgótá- 
ras vincseszter. Ha egészen pontosak óhajtunk lenni: sú- 
lyos teljesítményköltséggel jár a 8 kilobájtos lapok (a hely- 
foglalás alapegysége az SOL Serverben) megmozdítása. Er- 
go a Ouery Optimizer arra törekszik, hogy a lehető legke- 
vesebb 8k-s lapot kelljen megmozdítania. Vagyis lusta. De 
a lustaság, lám, fél egészség, hisz ez a stratégia adja egy- 
ben a leggyorsabb végrehajtást is! 


Költséghatékonyság 

Az Optimizer a következő módon választja ki a legolcsóbb 
végrehajtást: kiszámítja az összes lehetséges végrehajtási 
változat ,árát", s a legolcsóbb mellett dönt. Konkrét pél- 
dán könnyebb bemutatni a folyamatot; a VEVOK táblán 
dolgozzunk! (Ez egy fiktív tábla. Képzeljük egyszerűen ma- 
gunk elé.) A VEVOK táblában mondjuk tízezer rekord van 
(megy a biznisz), az átlagos rekordhossz 152 bájt. Így egy 
8k-s lapra mintegy 52 rekord fér el, a tábla pedig 193 da- 
rab 8k-s lapon terül el (52 " 193 - 10036). Vegyük ismét 
a bevezető-dühöngőben már említett lekérdezést, de ezút- 
tal optimizer hint nélkül: 


SELECT $ FROM VEVOK 
WHERE Name- "Kovács" 


És most tételezzük fel, hogy a VEVOK táblán van egy clus- 
tered index a Name, és egy nonclustered index a Name, 
Street mezőpároson. Ha véletlenül mégsincs, gyorsan hoz- 
zuk létre (fejben)! 


CREATE CLUSTERED INDEX NamelIndex on VEVOK(Name) 
Éözss 


CREATE NONCLUSTERED INDEX NameStreetiIndex 
"9, on VEVOK(Name, Street) 


Már ehhez az egyszerű lekérdezéshez is három különböző 
stratégia választható 

0 index nélküli futtatás 

"0 a clustered index használata (a rekordok fizikai sor- 
rendje az indexkulcsnak megfelelő) 
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"b a nonclustered index használata (hagyományos, poin- 
teres index) 

Az index nélküli futtatás költsége számítható a legegy- 
szerűbben: az összes 8k-s lapon végig kell szánkáznunk a 
Kovácsok megtalálásához (e stratégia neve Table Scan). Ez 
annyit tesz, mint 193 peták (-193 darab 8k-s lap). 

A clustered index árának kiszámítása már bonyolultabb, 
de még mindig könnyen megérthető. Mivel a clustered in- 
dex fizikailag lerendezi az adatokat az indexkulcs alapján, 
a VEVOK tábla rekordjai ideális fizikai sorrendben, Name 
szerint sorban terülnek el a lemezen. Így a Kovácsok meg- 
találásához egyszerűen rákeresünk az első Kovácsra (ez ed- 
dig kb. 2-3 peták, az index szintjeinek bejárása), majd szép 
sorban addig olvassuk a - helyes sorrendben lévő - rekor- 
dokat, amíg túlfutunk az utolsó Kovácson. Ez még akkor 
sem több, mint 19 peták (lap), ha a vevők tíz százaléka 
hallgat Kovács névre. Összesen tehát maximum 3--19, de 
ha szerencsénk van akkor inkább 2--5 vagy valami hasonló. 
A legnehezebb a helyzet a nonclustered, azaz hagyományos 
indexszel, lássuk miért! Ebben az esetben az index csak rá- 
vezet minket a megfelelő rekordokra, amelyek valamilyen - 
akár kaotikus - sorrendben helyezkednek el a táblában. No- 
ha a mi gondolatkísérletünkben a fizikai sorrend vételtlenül 
kedvező (mert pont a Name mezőn van egy clustered index 
is), ezt az Optimizer nem veszi figyelembe, mivel normális 
esetben a helyzet nem ilyen rózsás. Elvégre csak egy őrült 
pakol ugyanarra a mezőre egyszerre egy clustered és egy 
nonclustered indexet is :) A kaotikus elrendezés megvilági- 
tására álljon itt egy példa, a telefonkönyv. Azon a clustered 
index (a fizikai sorrend) vezetéknévi-keresztnév szerinti. De 
milyen sorrendben vannak benne a keresztnevek? Hol vannak 
a telefonkönyvben a Dzsonik és Dzsokik? Összevissza ugye? 
No most gondoljuk végig, ha van egy indexünk a keresztne- 
vek alapján, mely megmutataja melyik lapokon vannak 
Dzsokik, kábé hány oldalt kell megfognunk? Ez sokmindentől 
függ, és nem csak a Dzsokik számától, hanem azok eloszlá- 
sától is. Ha történetesen a káosz úgy hozta, hogy egy-két te- 
lefonkönyvoldalon nyüzsög a Dzsokik túlnyomó többsége, 
szerencsénk van. Ennél azonban valószínűbb a Dzsokik 
egyenletes eloszlása, amikor is annyi lapot kell érintenünk, 
ahány Dzsokink van. Az SOL Server is így kalkulál: a lehető 
legrosszabb esetre felkészülve annyi petákot számol fel a 
nonclustered index használatáért, ahány találatunk lesz. De 
hagyjuk a Dzsokikat, térjünk vissza a mérendő lekérdezésre. 
Ha az előző pont feltételezésével, azaz tízszázaléknyi Ko- 
váccsal számolunk (ami igazán magas arány), akkor a 
nonclustered index bizony ezer (!!!) petákba kerül, ami 
nyolcszor annyi, mint a table scan! 

Persze ha kevés Kovácsunk van, mondjuk egyetlen egy, ak- 
kor indexfa bejárásat1 peták az ár. A nonclustered index 
ára, hasznossága tehát alapvetően függ a találati aránytól. 


Az index-ráerőszakoló optimizer hintek kizárólag tesz- 
telési célból használandók, hisz lehet, hogy egy adott 
index ugyanazon a táblán gyorsítja a lekérdezést egy 
ritka mezőérték keresése esetében, de csúfosan lelas- 
sít(hat)ja ugyanazt, ha egy másik érték szerint kere- 
sünk. Ez itt kéremszépen a Clipper halála. Csak az 
intelligens adatmotorok képesek figyelembe venni az 
adatok eloszlását a lekérdezés futtatásakor! 
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Így hát ezt előre kell tudnia a Ouery Optimizernek. No de 


honnan? Ha azt írom 
WHERE A-75 


akkor vajon hány rekordot kapunk vissza? Egyet? 
Meglehet. Nullát? Hát, az is lehet. Ezeregyet? Noné, az 
is lehet! Jó lenne ide valami tudományosabb dolog... 


Indexstatisztika 

A Ouery Optimizer nem hasraütéses módon próbálja 
előre megbecsülni, hogy egy adott lekérdezés hány 
rekordot fog érinteni, hisz mint láttuk, a jóslás pon- 
tossága döntő fontosságú az indexek hasznosságá- 
nak eldöntésekor. Van neki ugyanis egy segédeszkö- 
ze, az úgynevezett indexstatisztika. Ez megmondja, 
hogy ha Kovácsot keresünk, akkor nagy valószínű- 
séggel mondjuk 253 találatunk lesz (és a noncluste- 
red index használata lassabb, mint a Table Scan, mert 
253:192), ha pedig Zubornyákot, akkor 2 rekordot 
kapunk, így ugyanaz az index most sokkal-sokkal ol- 
csóbb. Az alábbi ábra egy indexstatisztika idealizált 
képét mutatja, benne az előző két példával. Termé- 
szetesen a statisztika nem grafikus formában tároló- 
dik, megtekintése igazi kihívás (DBCC SHOWSTATIS- 
TICS), amivel most nem fárasztanám a tisztelt olva- 
sóközönséget. Majd MesterO-n meghekkeljük. 





Name 
Kovács 


Zuburnyák 


a Ilyen lenne az indexstatisztika diagramja, ha áb- 
rázolnánk 


A statisztika frissen tartása kulcsfontosságú. Ha 
ugyanis tartalma eltér a valóságtól, a Ouery 
Optimizer megtéved, és rosszkor mond áment az in- 
dexekre. Ennek következménye katasztrofális telje- 
sítményben mutatkozik meg. Az adatbázisokon gyá- 
rilag be van pipálva az , Auto Create Statistics" és az 
Auto Update Statistics". Listázzuk ki, hogy az in- 
dexeken be van-e pipálva az autostat: 


sp autostats vevok 
De azért csak hagyjuk úgy a pipákat, ha jót akarunk! 
Ha ennek ellenére gyanús tévedéseket vélünk felfedez- 


ni, használjuk az 


UPDATE STATISTICS VEVOK 
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parancsot, mely végigszalad a táblán, és felfrissíti az index- 
statisztikát (jó sok opciója van ennek a parancsnak, érdemes 


ai 
7 





TI 


ITT 





[7 
TT 


a 
MT 





XA 











végigolvasni az Online Bookban). Az sp. update- 
stats pedig az adatbázis összes táblájának összes 
indexén megcsinálja a statisztikafrissítést. És 
most térjünk a lényegre! Honnan a csudából tud- 
ható meg, hogy az SOL Server mit használ az 
egyes lekérdezések futtatásakor? 


Ouery Plan 

Az SOL parancsok fordításának harmadik lépése, a 
végrehajtási terv minden további nélkül megte- 
kinthető a Ouery Analyzer eszközzel, ha a Ouery 
menüből a , Display Execution Plan" menüpontot 
választjuk - csak győzzük értelmezni! Márpedig ér- 
telmezni muszály, mert a ,Designing..." vizsga te- 
le van olyan kérdésekkel, hogy ha ezésez a Ouery 
Plan, akkor mit kellene tennünk, hogy a lekérde- 
zés teljesítménye növekedjen. A problémát a plan- 
alkatrészek horribilis száma okozza. Üssük csak fel 
az Online Bookot a , Graphical Showplan" oldalon, 
és csodálkozzunk rá a rengeteg ikonkára. Hát nem 
bevehetetlen vár a mi SOL Serverünk? Ha egyszer- 
re próbálnánk feldolgozni, megérteni vala- 
mennyit, nyilván belepusztulnánk, ezért a kis lé- 
pések stratégiáját javaslom. Kezdjük talán ezzel: 


Table Scan 

Mi sem egyszerűbb: a lekérdezés nem használt 
indexet. Hogy miért? Hát vagy azért, mert drága 
volt, vagy azért, mert egyáltalán nem volt. Min- 
denesetre ez az ikon irtandó, minél nagyobb a 
tábla, annál nagyobb baj, ha hemzseg tőlük az 
alkalmazás. Ellentipp: ha egy tábla oly kicsiny, 
hogy elfér 1-2 darab 8k-s lapon, akkor ne is eről- 
ködjünk annak indexelésével, mert az 1 lapos 
Table Scan mindig olcsóbb lesz akármiféle index- 
használatnál! Nagy tábláknál azonban illik inde- 
xelni a keresésben szereplő mezőket. 


—— I 


c Table Scan 
Cost: 05 Cost: 1005 





o A Table Scan stratégia 


Húzzuk csak a Table Scan ikonja fölé az egeret! Mit 
látunk? A Ouery Optimizer által kiszámított árakat! 


Table Scan 
Scan rows from a tabbe. 


Physical operation: 
Logical operation: 


Table Scan 
Table Scan 


Estímated row count: 1 
Estimated row size: 3 
Estimated 1/0 cost: 

Estimated CPU cost: 

Estimated number of executes: 
Estimated cost: 

Estímated subtree cost: 


35 
0.0375 
400000) 


1.0 
0.037658(1009). 
0.0376 





5 A Ouery Optimizer számításai: sorok száma, 
költség, keresési feltétel stb. 


A Table Scan ára 0.037658 peták. És most következzen egy 


ikerpár: 
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sáb (Clustered vagy nonclustered) Index Scan és 
söB (Clustered vagy nonclustered) Index Seek 


Ez a két jómadár index használatára utal. A fenti, sokat 
emlegetett , kovácsos" lekérdezés így fut: 


ELECT " FROM VEVOK [VHERE Name-" Kovács" 








ő —ööwöÖ§ 
SELECT vevok.Namelndex 
Cost: Oz Cost: 1005 
5 Az Index Seek alatt olvasható a használatba vett in- 
dex neve, és ,, beszerzési" ára, százalékosan 


A (nonclusterd) Index Seek ára: 0,006408 peták. Egy nagy- 
ságrenddel olcsóbb, mint a Table Scan. De ne örüljünk ko- 
rán: az Index Scan (amelyiknek dagi nyíl van az ikonjában) 
becsapós. Ha ugyanis van egy táblán clustered index, töb- 
bé sohasem látjuk az előző, Table Scan ikont, mert olyan- 
kor clustered index scan látszik (mivel a fizikai sorrend 
megegyezik az indexsorrenddel) , még akkor sem, ha valójá- 
ban az történik. Kérdezzük ezt: 


SELECT $§ FROM VEVOK 
WHERE street5"sadsdf" 


És tekintsük meg a Ouery Plant: 


T FROM VEVOK 





Ouery text: SELECT 


5 





si vevok.Namelndex 
Cost: Oz Cost: 100£ 


a Az Index Scan néha Table Scan! 


Itt bizony huncutság van, mert a street mezőn nincs is clus- 
terd index, ez a Plan mégis Clustered Index Scanról beszél. 
Pedig ez biza Table Scan! Ára: 0.037658 peták, vagyis fillér- 
re ugyanannyi, mint a Table Scan ára - és ez nem véletlen! 


Lábas volt a fedőnevem 

Az Index Scan nemcsak hazudós-becsapós tud lenni, hanem 
nagyon hasznos is. Index Scan esetén tulajdonképpen tábla- 
ként használjuk az indexet, vagyis holmi ódivatú, Clipperes 
fabejárás helyett nekiesünk a legalsó szintjének, mintha az 
tábla lenne (az előbb láttuk: clustered esetén valóban a tábla 
van az index , alján") , és szépen végigfutunk rajta. Hol vehet- 
jük ennek hasznát? Netán tudatosan fel is használhatnánk? 
Emlékezzünk a nonclustered indexünkre, mely a (Name, 
Street) mezőkre készült. Most kérjük meg az SOL Servert, hogy 
listázza ki a vevőket utcanév, azon belül név szerint: 


SELECT Street, Name FROM VEVOK 
ORDER BY Street, Name 


Használni fogja vajon a pont fordított sorrendű indexün- 
ket? Gondoljunk ismét a telefonkönyvre (Last, First clus- 
tered index) . Ha keresztnév alapján kellene outputot produ- 
kálnunk, mire mennénk az indexszel? Semmire. Hacsak... 
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Vegyük észre, hogy az indexben benne van minden érték, 
ami alapján készült. Mint egy kicsi tábla. A mi noncluste- 
red indexünkben is benne van az összes Name és Street, 
még ha nem is a kívánatos sorrendben. Ha nincs jó index, 
akkor ugyebár Table Scanra fanyalodunk. De ha a lekérde- 
zés csak olyan mezőket kér, amelyek amúgy is megvannak 
az indexben? Sokkal gyorsabb az indexen Table Scanolni, 
mint a táblán! Sőt, ennek más előnye is van. Ha nem me- 
gyünk le a táblához az értékekért, akkor nem teszünk rá 
semmilyen zárat (lockot) sem! A fedő index (mely egy le- 
kérdezés összes mezőjét tartalmazza, mégha rossz sorrend- 
ben is) egy kincs. Ügyes használatával sokszorannyi párhu- 
zamos felhasználó dolgozhat adatbázisunkban! 


Matek 
Most pedig számoljuk meg, hány vevőnk van: 


SELECT count(t) FROM VEVOK 


Nem tudom, ki mire számított, én arra tippeltem volna, 
hogy emiatt nem megy végig sem táblán, sem indexen, ha- 
nem az egyik rendszertáblából megválaszolja. De nem. Pa- 
rádés outputot produkál: 


Ouery text: SELECT count(T) FROM VEVOK 





18 Bi 

—— hg —— jz ———— — S 
Cowmpute Scalar Stream regat. , vevok.NamesStree.. 

Cost: 04 Cost: 100£ 





Cost: 05 
a Hány vevő van? 


Végigfut a táblán a clusterd index mentén, s közben cso- 
portosítva számol (GROUP BY: ez a Stream Aggregate), 
majd az egyetlen csoport eredményét aláveti egy , skalari- 
zálásnak", amitől az egyébként is egy érték végre egy da- 
rab értékké válik, és kimehet az outputra. Úgy tűnik, egy 
kicsit elgaloppírozta magát. De ha megnézzük az ikonok 
alatt a költségeket, kiderül, hogy gyakorlatikag az index 
mentén történt végigfutás viszi el a költség egészét, így a 
fejben-feleslegesen-skalarizálás nem oszt, nem szoroz. Úgy 
deríthetjük ki pontosan, hogy mit bénázik egy ilyen egy- 
szerű SELECT-tel, ha összehasonlítjuk ezzel a kovácsszámo- 
ló lekérdezéssel (hány előfordulása van egy-egy névnek?) . 


SELECT Name, count(t) FROM VEVOK 
GROUP BY Name 


A Ouery Plan ugyanis pontosan ugyanaz. Az Optimizer nem 
tesz különbséget a GROUP BY nélküli, és a GROUP BY-os 
skaláris összegzések között. 

Hosszú történet a Ouery Optimizer, ígérem, visszatérünk rá. 
Legközelebb a zárolásokról mesélek, utána pedig - az októberi 
Hash! Cikkre építve - a kapcsolási (join) stratégiákat elemzem. 


Fóti Marcell 
MCDBA is. 
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Bevezetés 

Minden Microsoft fejlesztő számára egyértelmű: alapvetően 
meg fog változni az a háttér, amely támogatásával jelenleg 
Windows alkalmazásokat fejlesztünk. A radikális változás oka a 
.NET marketingnéven beharangozott technológiai csomag. A 
.NET egyik alapköve az XML. Keresztül-kasul XML-be botlunk a 
rendszerosztályok használata során is. Emiatt komoly támoga- 
tást várhatunk a szokásos XML-es feladatok elvégzéséhez is: 
értelmezés, XSLT transzformáció, érvényesítés (validation) sé- 
ma alapján. Valójában ennél sokkalta többet kapunk. Lássuk! 


Bemosakodás 

Aki még nem találkozott a .NET-tel, annak talán szokatlan lesz 
a cikkben található programok nyelvezete. A kódokat Cit (ejtsd: 
szí sárp) nyelven írtam, és a Beta2 állapotú .NET Framework-öt 
használtam fordításhoz és futtatáshoz. Mire ez a cikk az Ön ke- 
zébe ér már december lesz, amikor már lehet, hogy az Ön gé- 
pén a végleges verziójú .NET keretrendszer fog csücsülni. Ebben 
az esetben lehet, hogy a példa forráskódok nem fognak hibát- 
tanul lefordulni, mert megváltozott valamelyik .NET osztály de- 
finíciója. Nagyon nagy változás nem várható, de probléma ese- 
tén (és egyáltalán) bátorítom a kedves olvasót az MSDN Library 
használatára. Ez elérhető a [1] címen is, de CD-n vagy DVD-n 
megrendelve sokkal kényelmesebben használható. Microsoftos 
fejlesztő meg sem tud mozdulni nélküle. 

Attól, hogy valaki még nem ismeri a Ctt nyelvet nyugodtan ne- 
kiállhat a cikk olvasásának. A nyelv Cs-- (JAVA) hasonlósága 
miatt könnyen olvasható az előbbi nyelvek valamelyikének is- 
meretében. Kód írásakor már nem ilyen egyértelmű a dolog. 
Aki pedig szeretné közelebbről is megismerni a .NET-et, an- 
nak ajánlom figyelmébe a jövő januártól induló .NET-ről szó- 
ló sorozatunkat, ahol a kezdetektől elindulva hónapról-hó- 
napra fedezzük fel a .NET világát. 


Az MSXML és a .NET 

Cikksorozatunk eddigi részeiben az MSXML3, illetve néha az 
MSXML4 parser lehetőségeivel foglakoztunk. Ezek biztosítják 
számunkra az XML technológiák használatát COM alapon, töb- 
bé-kevésbé szabványos API-kon keresztül. Az MSXML4 már a 
jelenlegi XML, XSD (XML Schema Description), XSLT és XPath 
w3c ajánlásoknak megfelelően működik (a 3.0 még nem, hisz 
nem volt még kész az XSD a programcsomag írásakor). 

A .NET keretrendszer fejlesztése a legújabb XML technoló- 
giákkal párhuzamosan történik, így a termékben olyan új 
technológiák is benne vannak, mint például a SOAP. Emel- 
lett a .NET XML osztályok nemcsak egyszerűen az MSXML4 
funkcionalitást tudják, hanem sok új eszközt is tartalmaz- 
nak, amelyek segítségével egyszerűbben vagy gyorsabban 
lehet a megszokott feladatokat elvégezni. 

Ennek ellenére a .NET XML osztályok esetében szó sincs ra- 
dikális váltásról az MSXML-hez képest, nem úgy mint az ADO 
-5 c- ADO.NET esetén. Mivel a COM világ még sokáig el fog 
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éldegélni, az MSXMLx és a .NET osztályok alapszolgáltatásai 
egymással többé-kevésbé párhuzamosan fognak fejlődni, 
egészen addig, míg egyszer csak a Microsoft úgy érzi, itt az 
ideje túllépni a COM-on. Ez akkor következik be, amikor a 
legtöbb XML-t alkalmazó Microsoft termék már .NET alapú 
lesz (IE, Office, stb.). Mielőtt ez utolérne minket (azért ez 
nem holnap lesz) , érdemes megismerni a .NET XML osztályok 
szolgáltatásait. Nemcsak azért, hogy haladjunk a korral, ha- 
nem mert sokszor egyszerűbb lesz az életünk. 


Az XML, mint a .NET alapköve 

A COM világban az MSXML nem más, mint egy egyszerű COM DLL. 
Amelyik alkalmazás XML-lel akart foglakozni, az felhasználta a 
benne lakó objektumok szolgáltatásait. De ettől még a COM 
alapjainak semmi köze sem volt az XML-hez. Nem így a .NET. 

A .NET központi technológiái, a webszolgáltatások, ASP.NET, 
Remoting (- távoli objektumok aktiválása és metódushívása) , 
az alkalmazások konfigurációs állományai mind XML alapúak. 
De az igazán izgalmas lehetőség az adatelérést biztosító 
ADO.NET és az XML osztályok integrációja. Egy adatbázisle- 
kérdezés eredményét láthatom, mint memóriabeli objektu- 
mot, de ha kell, XML adatforrásként vagy adatfolyamként is 
kezelhetem. Az OLEDB által megvalósítani kívánt univerzális 
adatelérési stratégiát (amely nem terjedt el széleskörűen, lé- 
vén, hogy COM alapú, így a Microsofthoz kötődik) most az 
XML, mint mindenki által ismert adatreprezentáció révén az 
ADO.NET már sikerre viheti. A relációs és a hierarchikus világ 
közötti szakadékot valószínűleg sikerült áthidalni a szorosan 
összeintegrált adatelérési és XML kezelő osztályok segítségé- 
vel. De egyelőre maradjunk az alapszolgáltatásoknál. 


XML alaposztályok 

Az alapszolgáltatásokat nyújtó osztályok a System.Xml név- 
térbe vannak csoportosítva. Fizikailag ők a System.Xml.dil- 
ben találhatók meg, mely a többi alapvető assembly-vel 
együtt a c:winntimicrosoft.netWframeworkWw1.0.29144 
elérési úton található meg a Beta2 verzióban. Később is va- 
lószínűleg csak a verziószám változik meg. 

A legfontosabb alaptechnológiák külön névteret kaptak, így 
az XPath-szal kapcsolatos osztályok a System.Xml.XPath 
névtérben, az XSLT a System.Xml.Xsl-ben, a séma (XSD) 
osztályok a System.Xml.Schema, míg az objektumok állapo- 
tának XML formátumban történő tárolását és visszatöltését 
a System.Xml.Serialization névtér lakói látják el. 

Az egyszerű használat érdekében érdemes beimportálni eze- 
ket a névtereket a programunk elején a Ct using kulcsszó- 
val (VB.NET: Imports). Ettől nem lesz nagyobb a kész prog- 
ramunk, maximum tovább tart a fordítás. 


using System.Xml; 


using System.Xml.Schema; 


using System.Xml.XPath; 
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using System.Xml.Xsl; 


using System.Xml.Serialization; 


Az MSXML-től eltérően a .NET XML osztályok már eleve mo- 
dularizáltan, a könnyű bővíthetőség jegyében vannak meg- 
tervezve, kihasználva a futtatókörnyezet, a Common 
Language Runtime (CLR) objektumorientált lehetőségeit. 
Két absztrakt alaposztály alkotja az XML kezelés gerincét: 
XmlReader és XmlWriter. Az absztrakt szó azt jelenti, hogy be- 
lőlük nem lehet konkrét objektumpéldányokat létrehozni a 
new operátorral. A VB.NET-ben az absztrakt osztályokat a 
MustOverride (kötelező felüldefiniálni) kulcsszóval illetik, ami 
az abstract szónál kifejezőbb, habár az objektumorientált el- 
méletben az absztrakt szó a megszokott. A .NET nyelvek és 
maga a háttér kódkönyvtár is nagyon támaszkodik az objek- 
tumorientált elméletre (öröklés, virtuális metódusok, interfé- 
szek, egységbezárás satöbbi), ezért objektumorientált techni- 
kák pontos ismerete nélkül a .NET gondolkodásmódja elég ne- 
hezen érthető. Fogjuk tudni használni (kopi-paszta a példakó- 
dokból) , de tudatosan csak az O0OP ismeretek fényében érthe- 
tő meg a , miért". Emiatt az 00P-vel egy külön cikk keretében 
fogunk még foglalkozni, illetve a [2] címen elérhető tanfo- 
lyamon meg lehet ismerni részleteiben a Ct-pal együtt. 
Miért nem lehet létrehozni példányt egy absztrakt osztályból? 
Azért, mert a legtöbb metódus nincs megvalósítva bennük, azt 
majd a belőlük örökléssel leszármaztatott gyermekosztályok 
implementálják. Azaz ki van jelölve, hogy van neki mondjuk 
egy ReadAttributeValue() metódusa, de nincs konkrét megva- 
lósítása, azaz nincs programkód mögötte, mert a tényleges 
megvalósítást majd csak a leszármazott osztályok tudják meg- 
tenni, ők tudják mit kell csinálni egy adott metódusban. 

Az XmlReader XML adatfolyamok egyirányú, nem módosít- 
ható (read only, forward only) feldolgozására szolgál. A 
párja, az XmlWriter az XML 1.0 és az XML Namespaces aján- 
lásoknak megfelelő XML adatfolyamot képes magából onta- 
ni. Az adatfolyam forrása illetve célja sokféle lehet: fájl, 
hálózati adatfolyam, memória, egy String, HTTP csatorna, 
...), és ez is tetszés szerint bővíthető. 

Azaz XML-t olvasni és feldolgozni kívánó alkalmazások az 
XmlReader-t, XML-t generáló programok pedig az XmlWriter-t 
fogják használni. Ezen absztrakt alaposztályok tényleges hasz- 
nálatához a Microsoft többféle implementációt is írt. Az 
XmlReader-ből van származtatva az XmlTextReader, XmlValida- 
tingReader és az XmliNodeReader. Az első általános feldolgo- 
zásra, a második sémával szemben ellenőrzött (validation) ol- 
vasásra, míg a harmadik XML DOM-ból képes adatokat olvasni. 
Az XmlWriter-nek egy megvalósítása van, az XmlTextWriter. 


Alkalmazás 





XmlReader XmlWriter 


XmlTextWriter 


Pulse CEL ld XmiNodeReaderi 
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Amennyiben olyan funkcionalitásra van szükségünk, amelyet 
nem fednek le ezek az osztályok, bármikor leszármaztatha- 
tunk saját osztályt a fenti alaposztályokból, és ezek után 
csak rajtunk áll, hogy honnan olvassuk vagy írjuk az informá- 
ciót. Pont ez egy hatalmas előnye az általános tervezésnek. 


XMLReader 
Tekintsük meg az XmlTextReader osztályt működés közben! 


1 using System; 
2 using System.Xml; 


3 

4 public class XMLTeszt 

5 ( 

6 — public static void Main() 

7 € 

8 XmlTextReader r; 

9 r z new XmlTextReader("a.xml"); 

10 while (r.Read()) 

11 ( 

12 switch (r.NodeType) 

13 ( 

14 case XmlNodeType.Element: 

15 Console.WriteLine("Elem: " 

16 4 r.Name); 
úg while (r.MoveToNextAttribute()) 
18 i 

19 Console.WriteLine(" " 4 

20 r.Name t "z"" 4 r.Value $ """); 
21 É 

22 break; 

23 case XmlNodeType.Text: 

24 Console.WriteLine( "Szöveg: " 
25 4 r.Value); 
26 break; 

27 $ 

28 ) 

29 ) 

30) 


(A sorszámozás csak a könnyebb hivatkozás kedvéért van a 
példában. Ez nem Simonss basic. :) 

Létrehozunk egy XmlTextReader példányt 9. A konstruktor- 
ban rögtön megadjuk az olvasandó XML fájl nevét, így rög- 
tön készen állunk az XML adatfolyam olvasására. A Read() 
metódussal lépkedünk előre az adatfolyamban (0, amely 
mindaddig true-t ad vissza, míg el nem értük a forrás végét. 
Minden egyes olvasás után visszakapunk egy node-ot, ami- 
nek típusát a NodeType tulajdonság adja vissza. A fenti pél- 
dában csak kettővel foglalkozunk, a többit egyszerűen átlép- 
jük. A node fajták az XmlNodeType felsorolás (enumeration) 
típusban vannak deklarálva. Minden node-hoz tartozik ren- 
geteg tulajdonság, amelyeket további jellemzőkön keresztül 
érhetünk el. A 15-16. sorban például kiíratjuk az élkapott 
elem nevét. A 24-25. sor egy elem szöveges tartalmát írja ki. 
Figyeljük meg, hogy az elemek attribútumai nem jelennek 
meg egyedi módon, hanem az őket tartalmazó elemnél lehet 
őket kiolvasni. Egy elemen állva a MoveToNextAttribute()-tal 
végiggyalogolhatunk az adott elem összes attribútumán. Ez 
összhangban van az XML specifikációval, miszerint az attri- 
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bútumok logikailag NEM gyermekei az őket tartalmazó elem- 
nek, hanem csak annak kiegészítései, jellemzői. 

Az egyes attribútumok értékét és nevét ugyanazon Value és 
Name jellemzőkkel érhetjük el, mint az elemekét. Ha bele- 
gondolunk, az adatbázisokhoz hasonlóan az XmlReader-ben 
is van egy kurzor, ami mindig az aktuális node-ra mutat. A 
15. sorban egy elemre, a 20.-ban egy attribútumra, a 25.- 
ben egy elem szöveges tartalmára. 

A Read() és a MoveToNextAttribute() is ezt a kurzort moz- 
gatja, s közben kiolvashatjuk annak a node-nak a jellem- 
zőit, amin pillanatnyilag áll. 

A példát a 


csc xmlreader.cs 


paranccsal fordíthatjuk le. 
Legyen a bemeneti fájl: 


c?xml versionzc"1.0" encoding-"IS0O-8859-2"?5 
dcaNetAcademia?z 


ds 
2. 
3.  csoci labmeret-"45"5Soczó Zsoltc/socis 
4.  cmarci labmeret-"49"5c/marcis 

5. 


€/NetAcademiaz 
Ekkor a futtatás eredménye: 


Elem: NetAcademia 
Elem: soci 
labmeret- "45" 
Szöveg: Soczó Zsolt 
Elem: marci 
labmeret- "49" 


Látható, hogy sorban olvassa fel az XML fájlt, és ahogy elér 
egy-egy node-ot úgy visszatér a Read(), mi pedig kiíratjuk 
a kapott tartalmat. 

Olvasás közben számtalan hiba felléphet, leggyakrabban for- 
mátumbeli hibákra számíthatunk, azaz az olvasandó XML 
tartalom nem jól formázott, vagy egyszerűen nem olvasható 
a forrásállomány. Ilyenkor az XmIlReader dob egy kizárást 
(exception), melynek konkrét típusa XmlException. Erre fel 
kell készülnünk, azaz el kell kapnunk, és le kell kezelnünk. 

Az előbbi példára alkalmazva ezt a Main() metódus teljes 
tartalmát rakjuk bele egy try blokkba, és írjuk egy catch 
blokkot, ami lekezeli a kizárást: 


try 
( 

//Ami a Main()-ben volt. 
, 
catch(XmlException ex) 
( 


Console.WriteLine("Gáz van a " 4 ex.LineNumber 
$ ". sorban, a " 

4 ex.LinePosition t " karakternél."); 
Console.WriteLine("A hiba oka: " 


, 


4 ex.Message); 


Ha például nincs meg a megadott XML fájl: 
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Gáz van a 0. sorban, a 0 karakternél. 
A hiba oka: There was an error accessing 


file:///C:/Documents.../a.xml 


Ha rosszul formázott a bemenet, például kitörlöm a soci 
elem záró tagját: 


Elem: NetAcademia 
Elem: soci 
labmeret-" 45 


Szöveg: Soczó Zsolt 


Elem: marci 

labmeret-— "49" 

Gáz van a 5. sorban, a 3 karakternél. 

A hiba oka: The "soci" start tag on line "3" 
doesn"t match the end tag of "NetAc 

ademia" in file "file:///C:/Documents... /a.xml!. 


Line 5, position 3. 


Látszik, hogy elkezdett dolgozni, felolvasta a soci elemet, 
felolvasta a marci elemet, hisz azt hitte, hogy az a soci elem 
gyermekeleme, és akkor döbbent rá, hogy ez nem igaz, ami- 
kor az 5. sorban megtalálta a NetAcademia kezdőtagot. 

A példa felhívja arra is a figyelmet, hogy a .NET-ben vége 
a HRESULT-oknak, a hibakódok figyelésének és egyéb bo- 
hóckodásnak. Strukturált hibakezelést lehet és kell alkal- 
maznunk, ha nem tetszik akkor is, mert az alaposztályok is 
ezt használják. És ez így van jól. 


Az XmlReader és a SAX 

Nem, nincs semmi zenei vagy pajzán felhangja a címnek. :) 
Aki ismeri az XML DOM-ot, az már látja, hogy az XmiReader 
teljesen más felfogásban olvassa fel az XML doksikat. A DOM 
felolvassa a teljes fájlt, és felépít belőle egy fát, amelyben 
minden levélobjektum a forrásdokumentum egy-egy node- 
jának felel meg. Ha százmegás a forrás, akkor felépít egy több 
száz megabájtnyi memóriát fogyasztó struktúrát. Emiatt a 
DOM nem alkalmas nagy adattömegek feldolgozására. Mielőtt 
azonban kifütyülnénk a DOM-ot érdemes átgondolni, hogy a 
már felépített fában könnyedén lehet mászkálni előre-hátra, 
míg az XmlReader-nél szó sincs erről: csak előre megy. Vala- 
mint a DOM-ba betöltött XML dokumentum bármely részét 
módosíthatjuk, és a módosítást a DOM vissza tudja írni. 
1998-ban, az XML specifikáció és az XML DOM megszületése 
után hamar nyilvánvalóvá vált, hogy a DOM nem jó minden- 
re. A memóriaproblémáról már beszéltem. Sokszor nem aka- 
runk oda-vissza mozogni, csak előre, amelyet nyilvánvalóan 
sokkal hatékonyabban is meg lehetne tenni, nem kell betöl- 
teni az egész doksit a memóriába. Emellett sokszor nem ér- 
dekel minket a teljes XML forrás, csak annak egy része. A 
számunkra érdektelen részeket egyszerűen át akarjuk ugra- 
ni. A problémák megoldására kifejlődött egy másik XML 
elérési módszer, melynek neve SAX (Simple API for XML). Ez 
nem w3c ajánlás, ennek ellenére a legtöbb gyártó XML prog- 
ramcsomagjában megtalálható. Az MSXML is tartalmazza. 

A SAX push modellt használ. Ez azt jelenti, hogy a SAX parser 
elkezdi felolvasni a doksit, és amikor megtalál egy node-ot, 
akkor visszahívja az alkalmazásunk megfelelő metódusát. 
Ehhez nekünk implementálni kell egy ContentHandler inter- 
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fészt, amit a SAX API definiál, és a saját megvalósításun- 
kat kell átadni paraméterül a SAX parsernek. 


Push model 
LexicaReader 


LEN ESZTI 


Push model 
XmiTextReader 


Alkalmazás 


XmiNodeReader 





A módszer működik, gyors, teljesíti azokat a felsorolt igé- 
nyeket, amelyeket az előbb összeszedtünk, azonban ez a 
callback (visszahívásos) jellegű működés elég idegen a leg- 
több fejlesztő számára. Általában azt szeretjük, ha a mi ke- 
zünkben van a karmesteri pálca, és mi mondjuk meg, mi- 
kor mi történik a program folyamában. Itt viszont elindít- 
juk az értelmezést, és zúdulnak be a visszahívások a SAX 
readertől: ,nesze, itt egy elem, melynek jellemzői: ...", 
tessék, itt egy szöveges tartalom, kezdjél vele valamit"... 
Ha megnézzük, ez szinte ugyanaz az elv, mint amit a .NET- 
es XmlReader használ, csak abban mi cibáltuk elő a követ- 
kező node-ot a Read() hívásával. Ezért mondják, hogy a 
.NET-es megvalósítás pull jellegű. Megvan az összes jó tu- 
lajdonsága, mint a SAX-nak, csak könnyebb használni, 
mert mi jelzünk, ha kelt a következő node. 

Ha valaki mindenáron SAX-olni akar, akkor az MSXML-t kell 
használnia, mert a .NET-ben nincs SAX parser. 


XmlWriter 

Nézzük meg a visszafelé vezető utat! Hogyan lehet XML ki- 
menetet generálni nem hagyományos eszközökkel? Például 
összeragasztgatjuk sztringműveletekkel a kívánt XML kime- 
netet. Nagyon flexibilis, de miért kell nekem pontosan is- 
mernem az XML és a Namespace szabványt ahhoz, hogy XML 
tartalmat állítsak elő? Nem a kacsacsőrökről van szó, annál 
azért sokkal összetettebb dolgok is vannak a szabványban. 
Karakterentitások (zűrös karakterek) lekezelése, például az 
idézőjel (")helyett 8iguot;. A bináris információk Base64 
kódolása. Leellenőrizni, hogy jól formázott-e az összetákolt 
XML-nek látszó ASCII szöveg? Ezek nem rám tartoznak. 
Engem nem érdekel a pontos XML formátum, csak az, hogy 
milyen struktúrát, milyen információtartalmat akarok XML 
formátumban látni. Én elemekben és attribútumokban 
gondolkodom, az XML szabvány meg kacsacsőrökben és 
idézőjelekben. Másképpen fogalmazva engem csak az XML 
dokumentum Infoset-je érdekel, azzal akarok dolgozni, 
nem ASCII szövegekkel. Emiatt az első megoldás kiesett. 
Második ötletként létrehozok egy XML DOM objektumot, és 
azon keresztül már tényleg Infoset-ben gondolkodva tudom 
felépíteni a dokumentumot. Például azt mondom a DOM- 
nak, hogy adjunk hozzá egy soci nevű elemet, melynek szö- 
veges tartalma kelbimbó. Hogy ez a végén egy csocizkel- 
bimbóc/socis karakterfolyam lesz? Hogyne, de ne kelljen 
nekem ezzel törődöm. Magyarul, az Infoset-tel dolgozva a 
DOM megfelelő metódusaival felépítem a kimeneti doku- 
mentumot, és elmentem azt egy fájlba. A módszer működik, 
csak ugyanaz a probléma vele, mint ami olvasáskor is elő- 
jött: a memóriában rakjuk össze a kimenetet, és csak a leg- 
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végén írjuk ki fájlba. Ez kis doksiknál oké, nagyoknál gáz. 
Talán a SAX? Igen, a SAX-nak a vissza irányra is van 
streaming modellje, azaz tudok úgy XML kimenetet gene- 
rálni, hogy a memóriában mindig csak az aktuálisan gene- 
rálandó node van, a már elkészült tartalom folyamatosan 
íródik ki a kimeneti állományba. Aki COM világban szándé- 
kozik nagy XML állományokat generálni, az mindenképpen 
vegye fontolóra a SAX API MXXMLWriter objektumát. 

Nézzünk egy negyedik variációt, ami már .NET-re épít! Az 
XmlWriter nagyon hasonlóan gondolkodik, mint a SAX 
XMLWriter-e, csak egyszerűbb a használata. Lássunk egy 
egyszerű példát, ami a korábban látott XML kimenetet ge- 


nerálja: 


using System; 
using System.Xml; 


using System.Text; 


( 
public static void Main() 
( 


1 
2 
3 
4 
5 public class XMLTeszt 
6 
7 
8 
9 XmlTextWriter w; 


10 w z- new XmlTextWriter("b.xml", 

11 Encoding.GetEncoding( "IS0-8859-2") ) ; 
12 w.Formatting - Formatting.Indented; 
13 w.Indentation - 2; 

14 w.OuoteChar - Char.Parse("""); 

15 

16 w.WriteStartDocument ( ) ; 

17 w.WriteStartElement ( "NetAcademia" ) ; 
18 w.WriteStartElement("soci"); 

19 w.WriteAttributeString("labmeret" , 
20 XmliConvert.ToString(45)); 

gi w.WriteString("Soczó Zsolt"); 

22 w.WriteEndElement ( ) ; 

23 w.WriteStartElement ("marci"); 

24 w.WriteAttributeString("labmeret" , 
25 549"); 

26 w.WriteEndElement ( ) ; 

27 

28 w.WriteEndElement ( ) ; 

29 w.WriteEndDocument ( ) ; 

30 w.Close(); 

ál § 

ö3 
A kimenet: 


1 c?xml version-"1.0" encoding-"iso-8859-2"?5 
2 cNetAcademiaz 

3 £soci labmeret-"45"5Soczó ZsoltC/socis 

4 cmarci labmeret-"49" /5 


5 c/NetAcademia: 


Majdnem azonos a korábbival, de mégsem. Először is, az 
encoding értékében a betűk kisbetűkkel vannak írva, míg én 
kézzel írt példában naggyal írtam. Van jelentősége? Nincs. 
Aztán, én a marci elemet lezártam egy záróelemmel, az 
XmlWriter viszont helyben lezárta az elemet. Van különb- 
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ség a két formátum között? Mint szövegeket nézve termé- 
szetesen igen. Információtartalmában van különbség kö- 
zöttük? Nulla, semmi! Ezért találták ki az Infoset [3] szab- 
ványt, amin keresztül nem ASCII szöveget, hanem elvont 
fogalmakat, elemeket, attribútumokat, megjegyzéseket, ve- 
zérlő utasításokat és egyebeket találunk. A DOM, a SAX, és 
az összes .NET-es XML osztály is az Infoset-tel foglalkozik, 
a konkrét formátum csak ezen eszközök íróit érdekli. 

Mit látunk a példaprogramban? Létrehozunk egy XmlWriter 
példányt (0. Első paraméterként meg kell adnunk egy 
Stream-et, amibe fog csurogni a generált XML dokumen- 
tum, vagy egy fájlnevet és egy karakter kódolási osztályt. 
Mivel a nemzeti karakterek kezelése most nem a fő témánk 
(de még kapni fog egy teljes cikket a jövőben) , azért egye- 
lőre legyen elég annyi, hogy a magyar karakterkészlet he- 
lyes kezeléséhez a legtöbb esetben szükségünk lesz egy, a 
Kelet Európai nyelvek karaktereit leíró Encoding osztályra, 
amit a Encoding.GetEncoding(...)-gal kaphatunk vissza. 
Paraméterként a kódlap nevét vagy számát kell megadni, 
magyarhoz IS0-8859-2-t, vagy 1250-et. 

A továbbiakban megadjuk, hogy a kimenetben beljebb lesz- 
nek tolva a gyermekelemek 8, mégpedig 2 karakterrel 8. 
Az attribútumok szövegét határoló karaktert a OuoteChar 
jellemzőn keresztül aposztrőófra állítjuk. Az alapértelmezett 
az idézőjel. Nem feltétlen állítgatjuk át sűrűn, de jó tudni 
róla, hogy van ilyen lehetőségünk. 

A kimenetbe még nem generáltunk semmit, csak beállítot- 
tuk, hogyan viselkedjék az író. Jöhet a tartalom! Létrehoz- 
zuk az XML dokumentumot 69, ennek hatására elkészül az 
XML deklaráció, azaz a kimenet 1. sora. Az encoding attri- 
bútum értéke az induláskor beállított encoding-ból jön. 

A további tartalmat a sokféle Writexyz metódussal generáljuk. 
Logikus a felépítésük, ezért inkább a XmlConvert.ToString-et 
emelem ki €9. Ha van egy nem string típusú értékünk, akkor 
azt stringgé, szöveggé kell konvertálnunk, hisz a végered- 
mény egy szöveges dokumentum. Praktikusan olyan formá- 
tummá érdemes alakítani ezen típusokat, amelyekből könnyű 
őket visszaalakítani az eredeti jelentésükké - majd ha 
visszaolvassuk a doksit. Ebben segít az XmiConvert osztály, 
mely képes a legtöbb alaptípust stringgé ill. visszafelé, 
stringből az eredeti típusra konvertálni. Elemezgesse csak 
helyettünk a változatos lebegőpontos szám és egyéb típusok 
szöveges ábrázolását! Példánkban egy egész számot, a 45-öt 
konvertáljuk át egy , 4" és ,5" karakterekből álló szöveggé. 
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A WriteString() ügyel arra, hogy a kimenetben ne jelenhes- 
senek meg foglalt karakterek (idézőjel, 8. jel, stb.), azokat 
mind kódolja az XML szabványnak megfelelően. 

Ha bináris adatokat szeretnénk írni az XML kimenetbe, ak- 
kor azt először át kell alakítani szöveggé, lehetőleg valami 
szabványos algoritmussal. A Base64 kódolás erre teljesen 
jó, és ha erre van szükségünk, akkor a WriteBase64 metó- 
dus siet a segítségünkre. 


w.WriteBase64(new byte[(](54, 189, 26), 0, 3); 


Azaz egy hárombájtos tömböt íratunk ki Base64 kódolással, 
a 0. bájttól kezdődően, 3 byte hosszan. A kimenet: 


Nr0Oa 


A három bájtól négy karakter lett, hisz ez a kódolás 64 ki- 
meneti értékre, karakterre kódolja le a 256 féle értéket ki- 
használó bemenetet (bájt), így valahol el kell tárolni a 
kieső két bit tartalmát. 

Az XmlReader ReadBase64 metódusa örömmel fogadja és 
visszaalakítja a lekódolt szöveget bájttömbbé. Ezzel a mód- 
szerrel könnyedén tudunk bináris adatokat is pakolni egy 
XML dokumentumba. 


Zárszó 

A .NET XML osztályok két oszlopos tagját immáron - részben 
- megismertük. Sok mindent viszont még nem tárgyaltunk. 
Az XML DOM rendelkezésünkre áll .NET-ben is. Nem néztük 
meg hogyan működnek az XSL transzformációk, illetve ho- 
gyan lehet navigálni egy dokumentumban XPath-al. Ezeket 
a témaköröket fogjuk áttekinteni a következő számban. 

És ha már .NET, akkor se csüggedjen az Olvasó, ha az itt lá- 
tott programok kínaiul hatottak. Januártól egy új rovatot 
indítok az újságban, amely a .NET alapjaitól indulva fogja 
hónapról-hónapra kalauzolni Önöket a .NET nem rögös, de 
meredek útján. Akinek mélyebb és gyorsabb tréningre van 
szüksége, annak ajánlom a [2] megtekintését. 

Az XML rovat nem szűnik meg, de az valószínű, hogy egyes 
részeiben már .NET alapon fogunk gondolkodni. Annyi 
hasznos technológia lapul még az XML ládikájában, hogy 
évekig csak erről írhatnánk... 

De addig is kellemes, békés Karácsonyt és boldog új évet kí- 
vánok minden Kedves Olvasómnak! 


Soczó Zsolt 
Zsolt.Soczo (2onetacademia.net 


A cikkben szereplő URL-ek: 


[1]: Microsoft Developer Network Library http://msdn.microsoft.com 
[2]: Introduction to Ctt Programming for the Microsoft .NET Platform http://www.netacademia.net/courses/2124.asp 


[3]: XML Infoset http://www.w3.org/TR/xml-infoset 


[4]: Letölthető példák http://technet.netacademia.net/download/xml 
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Windows 2000 - Active Directory régi-új profilok 

K: Tudna valaki segíteni, hogy hogyan kell egy Windows 
2000-et visszahelyezni az AD-be úgy, hogy ne csináljon új 
profilt a felhasználónak? Újra kellet csinálnom a domaint 
hardverhiba miatt, és most az AD-ben (Active Directory) nin- 
csenek meg a gépek. Ha újra beléptetem őket, akkor meg tel- 
Jesen új profilt hoz létre a felhasználónak és lehet konvertál- 
gatni a régi beállításait, leveleit, Office újraaktivál, stb... A 
régi profilra meg azt mondja: ismeretlen. 

V: A megoldást, mint sok más esetben a Windows registry 
megfelelő kulcsának szerkesztésével oldhatjuk meg. 


"HKEY LOCAL MACHINENSOFTWAREMWicrosoftlWindows NTYV 
4 CurrentVersionlProfileList 


Ezen registry kulcs alatt vannak a felhasználók Security ID-i, 
alatt a user SID-jének megfelelő kulcs alatti ProfilelmagePath 
érteket kell úgy megváltoztatni, hogy a régi profilkönyvtárra 
mutasson, így a felhasználók régi profiljukat , visszakapják". 

Ha a user SID-ek is újak, akkor a fentiek nem elegendőek. 
A jogosultságokat is meg kell változtatni a profilkönyvtáron 
ÉS a HKEY CURRENT USER kulcson is (amit az ntuser.dat 
fájlból tölt be a rendszer)! 

1. Elsőként a régi profilkönyvtáron be kell állítani az ntfs 
jogosultságokat az új felhasználónak. (Alapértelmezés- 
ben az Administrators csoportnak, a SYSTEM accountnak 
és magának a felhasználónak van full control jogosultsá- 
ga az adott profilon) 

2. Másodiként a profilkönyvtár gyökerében lévő ntuser.dat 
registry hive-ban is be kell állítani az engedélyeket. Ez 
amiatt fontos, mert ha nem állítjuk be, akkor a felhasz- 
nálónak nem lesz joga a saját HKEY CURRENT USER kul- 
csára, és a belépés meghiúsul. Ezt megtehetjük regedt32- 
vel (be kell tölteni a struktúrát (hive) a HKEY USERS 
kulcs alá, módosítjuk az engedélyeket (permission), majd 
elmentjük (struktúra eltávolítása (unload hive) ). 

Meg lehet spórolni a registry szerkesztését a Vezérlőpult- 

Rendszer-Felhasználói Profilok (Control Panel-System- User 

Profiles) menüpont alatt. Itt az összes engedéllyel kapcso- 

latos műveletet automatikusan elvégzi a Windows a 

MÁSOLÁS(Copy to) funkcióval. Itt a HASZNÁLHATJA 

(Permitted to use) alatt kell megadni másolás előtt azt a 

felhasználót, akié a profil lesz. 

Forrás : Netacademia Windows 2000 Lista 


MS Exchange - elveszett jogok visszaállítása 

K: PST-ből (Personal Storage Folder) lett visszatöltve egy 
public folder, és a jogok elvesztek. Van arra valami scriptle- 
hetőség, hogy az almappák jogait be tudjam állítani, vagy 
marad a manuális szögelés az Outlook vagy az ExchAdmin- 
PublicFolders alatt? 
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DUPLA KV 





V: A Microsoft Backoffice Resource Kit tartalmaz két hasz- 
nos szoftvert a Public Folderek jogosultságainak ellenőrzé- 
sére és beállítására. 

0 A pfinfo.exe program parancssorból indítható és egy fájl- 
ban helyez el információkat a Public Folder jogosultsá- 
gairól. 

"0 A pfadmin.exe program parancssorból indítható és a Public 
Folder jogosultságainak beállítására, megváltoztatására 
szolgál. 

A probléma megoldásához nem kell ezeket a kényelmetle- 

nül használható eszközöket elővenni. Kiszolgálóoldalon a 

Public Folder tulajdonságainak beállításakor lehetőség van 

a beállított jogokat az alkönyvtárakra is átadni. Ezt a 

Propagate these properties to all subfolders" kiválasztásá- 

val oldhatjuk meg. Ez a következő képen látható: 







maláddesses ] Customátibzes ] Un ) Advanced ] 
a] FelderRepkesázn Stib] Repácston Schedde 











tte EXHTEST 


Homa új Las medied 
Home tervet. EXCHTEST 


Ceszd 
417700 1S1PM 4/17/00 VS2FM 





5 A public folderek beállításai lemásolhatók az alkönyv- 
tárakra is 


A beállítás a hierarchiában minden alsóbb könyvtár jogait 
megváltoztatja. Ha csak az adott könyvtár jogait kellene 
beállítani, akkor ez problémát okozhat! Van egy utolsó le- 
hetőség, az ,OK" vagy ,Apply" gomb megnyomása után. 
Feljön egy ablak, melyben kiválasztható a továbbadni kí- 
vánt tulajdonságok listája. 





Subfolder Propertier 


Apply these propertez to all subfolders. 

FT er pemmásztond 

TT Regbcation schedde 

TT Begicar 

TT Repbcation message importance 

TT Age ira for all repbcaz 

TT whether to hide írom the address book. 
TT Deleted ütem jetenton time 

TT lén administtáíve access to home sze 
TT Home Server 


For large numbers of subfolders thés operation may 
take along time. 


Cancel Hep 
o Mit másoljunk le a mappákra? 


Forrás : Netacademia Exchange Lista 
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MICROSOFT RESEARCH 


Millenium 


avagy hálózati 


A XXI. század kalmárja virtuális boltot nyit az információs sztrá- 
da egyik forgalmas csomópontjánál. Éppenséggel jól megy ne- 
ki, de mehetne jobban is. Merthogy a Karácsony az még min- 
dig Karácsony, és az Interneten is december végén van. Kény- 
telen hát jól felvértezni magát dögös kiszolgálókkal, hogy bír- 
ja az ünnepi rohamot. Bírja. Ez az év is elmúlt, és sajnos jövő- 
re sincs kilátás arra, hogyan hasznosíthatná méregdrága, a Jé- 
zuska következő látogatásáig lustálkodó számítógépeit. 

Ne írjon, ne telefonáljon! A Microsoft régóta tud a problé- 
máról. Egy ideig türelmesen figyelte az informatikus társa- 
dalmat, amely Szent Grálként tekintett a láthatatlan háló- 
zat problémájára, míg végül 1996-ban úgy döntött, hogy 
maga veszi kézbe ezt az ügyet (is). 

Millennium. Raktározzuk el memóriánkban ezt a nevet, mert né- 
hány éven belül egészen biztosan gyakrabban találkoznunk majd 
vele. (Nem a Windows 98 utódjáról beszélünk! Ez a Millennium nem 
az a Millennium!) A képernyővédő-szindróma már másnak is sze- 
met szúrt. Nemes dolog bekapcsolódni a SETI programba, a rák- 
kutatásba meg főleg, de itt most még ennél is többről van szó. 
A hangzatos fedőnév egy elosztott operációs rendszert ta- 
kar. Kalmárunk ennek módfelett örül, mert rögtön tudja, 
hogy így nem kell annyi dögös gépet vásárolnia. A vevőözön 
idején a Millennium replikálja a túlterheltség jeleit mutató 
webkiszolgáló tartalmát olyan gépekre, amelyek kihasznált- 
sága ekkor kisebb mértékű. Közös teherviselés van: a cél ér- 
dekében a munkaállomások éppúgy munkára foghatók, mint 
a kiszolgálók. Az áradat elvonultával az erőforrások újra 
felosztásra kerülnek az igények optimális kielégítéséhez. 

A Millennium a COM-- technológiára épül, és ugyanúgy keze- 
ti majd elosztott módon az alkalmazásokat, ahogy a mai 
operációs rendszerek teszik ezt egy központi számítógépen. 
A Microsoft, filozófiájának megfelelően, a bonyolult technológiát 
elrejti az avatatlan szemek elől. Kalmárunk az egész háttérfolya- 
matból mit sem lát, és saját bevallása szerint egy cseppet sem 
érdekli, amíg a vevők elégedettek a kiszolgálás sebességével. 
Üzleti szempontból az előny jól látható: a feldolgozási telje- 
sítmény, a memória és más eszközök optimális elosztásával 
egy adott feladatot a leghatékonyabban lehet végrehajtani, 
ami idő és pénz megtakarítását jelenti. Közelítsük most meg 
a lehetséges előnyöket felhasználói oldalról: kihasználhatjuk 
a hálózaton lévő eszközök funkcióit, felgyorsul az alkalmazá- 
sok végrehajtása, nem kell többé foglalkoznunk a hely kérdé- 
sével, hiszen egy nagy számítógéppel nézünk szembe. 
Tegyük fel például, hogy diktálni szeretnénk egy szöveget a kis 
palmtopunknak, amely majd a hangot átalakítja elektronikus 
dokumentummá. Erre bizony nem egy palmtop a legmegfelelőbb 
eszköz. Gond egy szál se, biztosan van a hálózaton nagyobb tel- 
jesítményű gép is, amelyre átterhelhető a feladat. Ezt persze 
legfeljebb sejthetjük, hiszen, az egészből semmit sem érzéke- 
lünk - hacsak nem azt, hogy a palmtop hihetetlenül gyors. 
Nem tudom más hogy van vele, de én bizonyos munkáimból 
két példányt is kénytelen vagyok tartani: egyet a munkahelyi, 
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egyet az otthoni gépemen. Ha az egyiken változtatok, indul- 
hat a cserebere. Milyen szép is lesz majd, ha nem kell azon 
gondolkodnom, hogy hol van az x.txt, egyszerűen csak meg 
kell nyitnom. A Millennium majd szépen megkeresi helyettem. 
A kutatás két fő területre összpontosul. Az egyik az absztrak- 
ció mértékének növelése, hogy a programozók számára az in- 
formáció a mainál egyszerűbb formában jelenjen meg. A má- 
sik az önbeállítás és az önszabályozás kérdése. A tervek sze- 
rint a hálózatba kerülő új eszközöket automatikusan felisme- 
ri majd, miután a munkák elosztását az új erőforrásviszonyok- 
hoz igazítja. Az elosztott rendszerek vizsgálatával ellentét- 
ben, ez a két terület eddig nagyon is kevés figyelmet kapott. 
Bár az automatikus eszközfelismerést a Microsoft Universal 
Plug and Play-e és a Sun Microsystems Jini-je is jól tudja, itt 
megintcsak többről van szó. Az egyik kutató példájával élve 
e két megoldás ahhoz hasonlítható, mikor a telefonokból te- 
lefonrendszert építünk. A Millennium ezzel szemben olyan, 
mintha úgy beszélhetnénk valakivel, hogy ő közben akár a vi- 
lág túlsó felén is lehet, ráadásul még arról sincs tudomásunk, 
hogy a beszélgetéshez egyáltalán telefont használunk-e. 

A Microsoft szándékai szerint a kutatási eredmények már az 
elkövetkezendő néhány évben is bekerülhetnek egyes ter- 
mékekbe. A kutatócsoport már több prototípussal is előállt, 
amelyek jól megvilágítják egy Millennium típusú operációs 
rendszer rendkívüli lehetőségeit. 

A Coign például nem elosztott alkalmazásból elosztottat ké- 
szít anélkül, hogy ehhez az eredeti kódra is szüksége len- 
ne. A mai alkalmazások így könnyen és gyorsan átalakítha- 
tók a Millennium követelményrendszere szerint. 

A COP a számítógéphez csatlakoztatott eszközök megosztását te- 
szi lehetővé, legyen szó akár egérről, billentyűzetről, monitorról, 
merevlemezről vagy bármi másról. A felhasználók és az alkalma- 
zások számára azonban a használatba vett eszközök egyetlen 
számítógépként jelennek meg, ami az absztrakció fokozódását és 
az információk érthetőbb megjelenítését mutatja be. 

A Millennium Falcon (amely, mint tudjuk, másfélszer gyorsab- 
ban repül a fénynél :-) jelentősen csökkenti az alkalmazások 
különböző gépeken futó komponenseinek kommunikációjához 
szükséges időt. Ez a prototípus azt hivatott szemléltetni, 
hogy az információ feldolgozásának sebessége közel olyan 
nagy lehet akkor is, ha az adatoknak több számítógép között 
kell áramlani, mintha azokat csak helyben használnánk fel. 
Tehát ismét egy forradalmi technológia (vagy inkább techno- 
lógiai forradalom?) születésének lehetünk tanúi. A Millen- 
nium a számítógépesített eszközök hálózatát egyetlen gi- 
gantikus elektronikus aggyá szervezi. Erőforrás itt kihaszná- 
latlanul nem maradhat. A Millennium a feladatok végrehaj- 
tásának hatékonyságát tekintve már-már az emberi agy mű- 
ködésére, vagy legalább ennyire a Lovelock elméjében meg- 
fogant élő bolygóra, a Gaiára emlékeztethet bennünket. 


(Zacco) 
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SZABVÁNYOK 





Ehavi számunkban két kísérleti szabványt mutatunk be: a 
repülő adathordozókon alapuló IP datagramtovábbítás ere- 
deti változatát (RFC 1149, [1]), valamint a szolgáltatásmi- 
nőségi (Ouality of Service) elemekkel kibővített, jóval kifor- 
rottabb változatot (RFC 2549, [2]), amely az első után 
csaknem tíz évet váratott magára (érdekes módon, mindket- 
tő kiadási dátuma április 1). 


RFC 1149: IP datagramok átvitele repülő adathordozók 
segítségével 

Az RFC 1149 kísérleti szabvány jellemző felhasználási köre a 
Városi Hálózatok (Metropolitan Area Network, MAN) területe. 
A repülő adathordozókon (avian carrier) alapuló hálózat nagy 
késleltetési idejű, kis sávszélességű, kis magasságú szolgál- 
tatás. A hálózat topológiája pont-pont, hordozónként; kora 
tavasztól több hordozó egymás zavarása nélkül képes a háló- 
zati csomópontok (hostok) közötti egyidejű adatátvitelre. 
Mindez a 3D adatátviteli térnek köszönhető (szemben az IEEE 
802.3 (Ethernet) 1D adatátviteli terével). A rendszer beépí- 
tett csomagütközés-elkerülési megoldással rendelkezik. 
Egyes más megoldásokkal (pl. mikrohullámú rendszerekkel) 
ellentétben nem okoz gondot, ha a hálózati csomópontok ta- 
karásban vannak. Nagyobb városokban (pl. Velence) kapcso- 
latorientált szolgáltatás is rendelkezésre áll, általában köz- 
pontosított csillagtopológiában (lásd Szent Márk tér). 


Az adatátviteli keretformátum 

Az átvinni kívánt IP datagramokban található adatokat hexa- 
decimális formában kis papírra nyomtatjuk, majd azokat felte- 
kerjük. A kis tekercset ezután a hordozó lábára rögzítjük. A 
datagram széleit szigetelőszalaggal védjük. A sávszélességet a 
lábak hossza korlátozza; az egyidejűleg átvihető adatmennyi- 
ség (Message Transfer Unit, MTU), paradox módon a hordozó 
korával egyenes arányban nő. Az MTU tipikus mérete 256 mil- 
ligramm (a datagramok méretét szükség esetén ki lehet tölteni) . 
Az adat megérkeztekor a fogadó eltávolítja a szigetelősza- 
lagot, majd a datagramot szkennerrel elektronikus formá- 
tumba alakítja vissza. 


Egyéb jellemzők 

A rendszer további jellemzője a beépített féreg-felismerés 
és megsemmisítés. A sérült hordozók idővel regenerálják 
önmagukat. A rendszerben nem ismeretes a broadcasting 
fogalma, viharok adatvesztést okozhatnak. A hordozó az 
adatot többször megpróbálja kézbesíteni, mielőtt eldobná. 
A hordozók nyomkövetését segítik az automatikusan létre- 
jövő ,bejegyzések" (utcákon, háztetőkön, köztéri szob- 
rokon). 


RFC 2549: Minőségi szolgáltatás - Ouality of Service 
Az RFC 2549 számos helyen javítja, illetve új elemekkel 
egészíti ki az eredeti szabványt (bár továbbra is a ,,kísérle- 
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Adatátvitel 


galambpostán 


ti" (Experimental) státuszt kapta). Az új változat minőségi 
szinteket vezet be: Concorde, Business Class és turista- 
osztály. A Concorde és a Business Class külön előnye, hogy 
semmilyen más adatátviteli metódus során nem jutunk 
törzsutaskedvezményekhez. 

A szolgáltatás szintjét a hordozó szárnyára ragasztott vo- 
nalkóddal jelzik. Amikor a hordozó az útválasztóhoz ér, a 
vonalkódolvasó leolvassa az adatokat, majd a hordozót 
beállítja a várakozási sorba. A hordozó itt addig vár, míg el 
nem indulhat a célállomás felé (a várakozás során a hordo- 
zó esetleg alhat egy kicsit). A hordozókat a várakozási sor- 
ban piros festékkel törlésre jelölhetik ki. 

A súlyozott sorbaállítási algoritmus (Weighted Fair Oueuing, 
WFO) mérleg segítségével, az alábbi ábra alapján használ- 
ható (ábra az eredeti dokumentumból) : 


5 Weighted Fair Oueuing 


Amint az az ábrából is látható, a hordozók a hosszabb vá- 
rakozás esetén nyomokat hagyhatnak. A repülő adathordo- 
zók általában nem használják a hidakat (bridges), illetve az 
alagutakat (tunnels) a hálózati csomópontok között. A 
beágyazást (encapsulation) folpackkal oldhatjuk meg. 
Struccok is használhatók alternatív hordozóként: ezek na- 
gyobb adatcsomagok egyidejű átvitelére alkalmasak, vi- 
szont lassabbak, valamint a tartományok között kénytele- 
nek a hidakat (bridges) igénybe venni. Manapság divat a 
pingvinek használata is, azok ugyancsak nem tudnak repül- . 
ni (viszont ritkábban fagynak meg). 

A multicasting csak klónozással oldható meg. A hordozó el- 
vesztésével is számolnunk kell, ha éppen azt a fát vágják ki, 
amin a fészek található. A hordozók átlagos élettartama 
(Time to Live, TTL) 15 év. A hordozók nem állnak lexikai 
sorrendben, viszont gyakran szerveződnek V-alakba. 


A szabványok gyakorlati alkalmazása 

Nem megbízható hírforrások szerint két holland informati- 
kus megpróbálkozott a gyakorlati alkalmazással: állítólag 
egy völgy két oldala között próbálkoztak ,pingeléssel"7. A 
próba sikerrel járt, bár a késleltetés elég nagy volt, az egyik 
csomag ugyanis félúton leszállt egy háztetőre turbékolni... 


Fülöp Miklós 
mick 2netacademia.net 


eds etT EZ ALAN AT 


[1] http://www.ietf.org/rfc/rfc1149.txt 
[21] http://www.ietf.org/rfc/rfc2549.txt 
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Hogyan írjunk 


karbantarthatatlan 


kódot? 


Bevezető 

Ahhoz, hogy meghiúsítsuk a kódunkat karbantartó progra- 
mozó munkáját, meg kell értenünk, hogyan gondolkodik. 
Megkapja a monumentális programunkat. Nincs ideje, hogy 
elolvassa az egészet, és még kevesebb, hogy meg is értse 
azt. Minél gyorsabban meg akarja találni azokat a pontokat, 
ahol változtatnia kell a programunkon, lehetőleg úgy, hogy 
a változtatásnak nem lesznek káros mellékhatásai. 

Ő egy WC papír csövén keresztül látja a kódunkat: egyszerre min- 
dig csak egy pici részét látja a programunknak. Biztosak akarunk 
lenni afelől, hogy ebből soha nem áll neki össze a nagy kép a 
programunkról. Minél jobban meg akarjuk nehezíteni a dolgát, 
amikor egy számára fontos kódrészletet keres. De ami még fon- 
tosabb, hogy a lehető legkínosabbá kell neki tenni, hogy bármi- 
lyen apró részletet is biztonságosan átugorhasson. 

A programozók a konvenciók miatt jól érzik magukat egy kód- 
ban. Azonban hébe-hóba ravaszul áthágva a konvenciókat, ar- 
ra kényszeríthetjük a kódunkat karbantartó fejlesztőket, hogy 
nagyítóval olvassák és értelmezzék kódunk minden sorát. 
Előbb-utóbb észrevesszük, hogy egy programnyelv összes 
funkciója magában rejti a karbantarthatatlan kód írásának 
lehetőségét, csak megfelelően vissza kell velük élni. 


Elnevezések 

A karbantarthatatlan kód írásának alapvető titka a változók 
és metódusok művészi elnevezése. Ez a fordítóprogramokat 
egyáltalán nem érdekli, viszont hatalmas mozgásteret hagy 
a karbantartó programozók megzavarására. 


A Keresztnevek kézikönyvének új felhasználása 

Ha megvesszük a fenti könyvet, akkor soha nem fogyunk ki 
jó változónevekből. A Mari remek név, és még könnyű is gé- 
pelni. Emellett, ha könnyen gépelhető nevekre vágyunk, 
használjuk ki billentyűzünk szomszédos betűit, így remek 
asdf vagy erty neveket kapunk. 


Egybetűs változónevek 

Ha a-nak, b-nek, c-nek hívjuk a változóinkat, akkor az egy- 
szerűbb szövegszerkesztőkben nehéz lesz rájuk keresni, hisz 
nagyon sok szó tartalmazni fogja őket. Emellett senki nem 
fogja tudni melyiket mire használtuk fel. Ha valaki megkér- 
ne, hogy felejtsük el azt a Fortranban bevezetett szokást, 
miszerint a ciklusváltozókat i, j és k betűkkel jelölik, és ar- 
ra kér, hogy cseréljük ki őket ii, jj, kk nevekre, emlékeztes- 
sük arra, mit tett a spanyol inkvizíció az eretnekekkel. 


Kreatív elírások 

Ha arra kényszerítenek minket, hogy beszédes neveket ad- 
junk a változóknak, akkor írjuk el őket. Ha néha elírunk egy 
nevet, néha nem, akkor könnyen kilőhetjük a fejlesztőesz- 
közök keresési funkcióit. 
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Legyünk elvontak 

A változók és függvények elnevezéseiben használjunk minél 
elvontabb neveket: az, bármi, adat, kezelő, cucc, izé, eljá- 
rás, és használjunk számokat is bennük: EljárásX23, Végre- 
hajtAdatFüggvény, Csináld, KezeldleAzAdatokat3. 


Rokonértelmű szavak használata 

Unaloműzésként használjunk minél többféle rokonértelmű 
szót ugyanannak a fogalomnak a leírására. Pl. megjelenít, 
megmutat, kijelez. Homályosan utaljuk arra, hogy finom kü- 
lönbségek vannak közöttük, amikor valójában teljesen azono- 
sak. Ezzel ellentétben, ha két függvény között jelentős kü- 
lönbség van, használjuk rájuk ugyanazt a szót. Például a 
nyomtat jelentse azt, hogy papírra nyomtatni, de azt is, hogy 
fájlba írni, vagy a képernyőn megjeleníteni. Semmilyen körül- 
mények között ne engedjünk a követelésnek, hogy szójegyzé- 
ket írassanak velünk, ami egyértelműen lefektetné a projekt- 
ben használt szavak jelentését. Ez egyértelmű megszegése 
lenne az információelrejtés tudományos elméletének. 


Használjuk más nyelvek többesszámú szavait 

Például egy VB program nyilvántartja a ,statii"-kat, ame- 
lyeket különféle , Vaxen"-ekből kapunk vissza. Nagyszerűen 
használható nyelvek az Esperanto, a Klingon és a 
Hobbitese. Valamelyik szláv vagy északi nyelv is megfelelő 
lehet. Így programunk egyúttal a világbékét is szolgálja. 
Ha a kimeneti ,kanal" nincs lezárva, akkor írjunk bele 3 
sPripremu"-t. Vagy egy elágazásban, ha a valaki ,uzeri" ne- 
ve , Björk", akkor küldjünk neki , irgumburgum" üzenetet. 


Használjuk újra fel a neveket 

Ha az általunk használt nyelv megengedi, adjuk ugyanazt a 
nevet osztályoknak, konstruktoroknak, metódusoknak, tag- 
változóknak, tulajdonságoknak, paramétereknek és lokális 
változóknak. Külön pont jár a () blokkokban újradefiniált 
lokális változókért. A fő célunk, hogy a kódunkat olvasó 
programozó kénytelen legyen kielemezni minden példány 
érvényességi területét (szkópját). Javaban például érdemes 
közönséges metódusokat konstruktoroknak álcázni. 


Használjuk ki a fordítók maximális azonosítóhosszát 

Ha például a fordító csak az első 8 karaktert veszi figyelembe 
egy azonosító feldolgozásakor, akkor változtassuk a nevek vé- 
gét. Egyszer legyen karakter beállít máskor karakter kinyom- 
tat. A fordító mindkettőt karakter-nek fogja értelmezni. 


Az aláhúzás a mi jóbarátunk 
Használjukaz ésa  -t mint változóneveket. 


Ékezetes betűk 
Nekünk magyaroknak különösen kedves a módszer. Használ- 
junk ékezetes betűket, ahol lehet: 
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DEVELOPER 
typedef struct ( int i; ) ínt; 


Szerencsére sokszor nehéz észrevenni, hogy van-e ékezet 
egy betűn. Emellett különös örömet okozunk egy olyan em- 
bernek, akinek a nyelvében nincsenek ékezetes betűk, így 
ha ki akarja bővíteni a programunkat meg sem találja a 
megfelelő betűt a billentyűzetén - mert nincs is rajta. 


Keverjük a nyelveket 

Véletlenszerűen keverjünk össze különböző nyelveket a válto- 
zók elnevezésénél. Például PendingBorítéks (c). Ha a főnökünk 
rákérdez miért nem az általa megadott nyelvet használjuk, ak- 
kor mondjuk el neki, hogy az általunk választott nyelven sok- 
kal könnyebben tudjuk összeszedni a gondolatainkat. Ha ez 
nem elég neki, akkor emlegessük fel neki a nyelvi diszkriminá- 
ciót, és ebből kifolyólag fenyegessük meg nagyösszegű perrel. 


Nevek a matematikából 
Válasszuk matematikai operátorok neveit változónévként: 


Nyitózárójel - (osztás t szorzás) / egyenlő 


A kis I nagyon hasonlít az 1-re 

A long típusú konstansokban használjuk kis I-t nagy L he- 
lyett. Így például a 10l-et könnyen 101-nek lehet olvasni, 
míg a 10L-t senki nem tévesztené el. 


Használjuk újra a globálisan definiált neveket mint private 
változókat 

Deklaráljunk egy globális tömböt az A modulban, majd dek- 
laráljuk egy private-ot a B modul fejlécállományában. Így a 
B modult programozva úgy tűnik, mintha az A-ban definiált 
globálisat használnánk, pedig nem. A megjegyzésekben ter- 
mészetesen ne tegyünk erről említést. 


Használjuk újra a változóinkat 

Ha a programozási nyelv megengedi, használjunk fel újra 
változóneveket teljesen más célokra. Hasonlóan, ugyanazt 
az átmeneti változót használjunk különböző célokra, ve- 
remhely spórolás címén. Az ördögi variant típust kihasznál- 
va (VB :) változtassuk meg a változó típusát vagy értelme- 
zését. Például egy hosszú függvény elején rakjunk bele egy 
tömböt, majd a függvény közepe táján konvertáljuk át az 1- 
gyel kezdődő címzésű tömböt 0 kezdetűvé. Semmiképpen 
ne dokumentáljuk a változtatást. 


Félrevezető nevek 

A metódusaink mindig csináljanak egy kicsit többet, vagy keve- 
sebbet, mint amire a nevük utal. Például egy ÉrvényesE(x) (eb- 
ben a magyar miatt már több tanács is benne van) mellékesen 
átkonvertálhatja x-et binárissá, és eltárolhatja adatbázisban. 


objAlma, objConn, objRS 
Minden osztálypéldány nevét kezdjük o vagy obj betűkkel, 
jelezve, hogy nagy, polimorfikus képben gondolkodunk. 


Érthetetlen filmutalások 

Használjunk olyan konstansneveket, mint LancelotKedvencSzine 
a kék helyett, és adjunk neki értékül valamilyen hexa színkó- 
dot: $0405FA. A képernyőn ez a szín egy közönséges kéket 
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fog eredményezni, azonban a karbantartónak nem lesz kön- 
nyű dolga kitalálni azt. Csak a Monthy Python és a Szent Grál 
lelkes ismerői tudják, hogy Lancelot kedvenc színe a kék. Ha 
meg valaki nem tudja fejből idézni az összes Monty Python 
filmet, akkor hogy meri magát programozónak nevezni? 


Álcázás 


. A karbantarthatatlan kódírás művészete az álcázás művé- 


szete. A dolgok elrejtéséé, vagy hogy másnak tűnjenek a 
dolgok, mint amik. Sok trükk azon alapul, hogy a fordító- 
programok képesek olyan finomságok észrevételére és keze- 
lésére, amire az emberi szem és egy egyszerűbb szövegszer- 
kesztő nem képes. Tanuljunk a profiktól! 


Kód, ami megjegyzésnek tűnik, és viszont 
Írjunk olyan kódrészeket, amelyek megjegyzésblokkban 
vannak, de ez első ránézésre nem tűnik fel. 


for(j-O; jcarray len; jt -8) 

( 

total 4- array[jt0 ]; 

total 47 array(jtl ]; 

total 4t- array[jt2 ]; /t A ciklus középső része 
total 4- array[jt3]; : ki van bontva a 

total 4t- array[jt4]; t nagyobb sebesség kedvéért. 
total 4- array[(jt5]; §/ 

total tz array[jt6 ]; 

total 4- array[jt7 ]; 

, 


Észrevették, hogy a középső három sor megjegyzésben van? 


Rejtsük el a makrók definícióját 

Rejtsük el a makrók definícióját ostoba, értelmetlen meg- 
jegyzések közé. A programozók elunják végigolvasni a hosszú 
megjegyzéseket, így nem veszik észre a köztük megbúvó 
makrókat. Feltétlen legyen olyan a makró, hogy például egy 
egyszerű értékadást cseréljen le valami bizarr műveletre: 


$fdefine a-b a-0-b 


Tűnjünk elfoglaltnak 
Írjunk függvényeket makróként, amelyek egyszerűen meg- 
jegyzésekbe teszik a paramétereket: 


tdefine fastcopy(x,y,z) /txyzr/ 


fastcopy(arrayl, array2, size); /t nem csinál 


semmit t/ 
Szabadon fordította: Soczó Zsolt 


[1] Az eredeti, teljes szöveg (angolul) 
http://mindprod.com/unmaint.html 

[2] Letölthető példakódok: 
http://technet.netacademia.net/download/ szilveszter 
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Szilveszter! 
Dupla KV 


K: Gondoltam megosztom Veletek mai szívásom egy notebookkal: 
Ma délelőtt egy Mezei Notebook User (MNU) felhív, hogy fur- 
csán fagyogat a gépe, méghozzá akkor, ha felkapcsolják a vil- 
lanyt a szobában. Mondom neki ,,peeeersze... amikor a vil- 
lanyt felkapcsolják... hehe... én meg a helyi káplár vagyok". 
De ő csak mondja, hogy így van, vazze, nézzem meg. Felbak- 
tatok, és látom is, villany ég notebook szétszállt - csak a 
kikapcs segít. Láttam már szétfagyott gépet, úgyhogy restart, 
és várok, mikor, és mitől száll el megint. De hiába vártam 
semmi. MNU közli, hogy így nem fog elszállni, de felkapcsolja 
a lámpát, és majd akkor. Nem hittem a szememnek, a gép 
azonnal lefagyott. , Aaaaa" gondoltam magamban. Biztos vé- 
. letlenül történt. Gyors restart, Task Manager be, és nézzük mi 
történik. Hát semmi. MNU ismét megjegyzi, hogy kapcsoljuk 
fel a lámpát és... agyam eldobom megint szétszállt. No ennek 
fele se tréfa, biztos szívatnak, kandi kamera van a szobában, 
de megnyugtatnak nincs szívatás. De akkor mi a frász van??? 
Ismét restart. Task Manager be, lámpa fel, gép elhal. Hmmm. 
No mégiszer. Detto. Ekkor arra gondoltam, hogy tutira baj le- 
het az árammal meg a táppal, így nézzük mi van, ha akkuról 
megy a gép - de az eredmény ugyanaz. Kezdett a dolog egyre 
misztikusabbá válni, de nem adtam fel, kell lennie rendes ma- 
gyarázatnak!! Ekkor jöttem rá, hogy ezekben a gépekben van 
infra is, ez lehet a bűnös. Gyorsan leragasztottam, gép be, 
lámpa fel - semmi. No mégiszer... Semmi. Ok ragacs le - sem- 
mi, lámpa le - semmi, lámpa fel - halál. Ez az! Megvan!!! 
Most már csak az érdekelne, hogy a rákban döglik meg egy T... 
4200 notebook infrája úgy, hogy - ha felkapcsoljuk a szobában lé- 


Így ha esetleg Ti is találkoztok MNU-val, aki közli, hogy ha 
felkapcsolja a lámpát, lefagy a gépe, hát... én már nem rö- 
högném ki. Annyit még hozzá lehet tenni, hogy azóta felhív- 
tam a T... szervizt, akik felvették a kapcsolatot a németek- 
kel. Kiderült, hogy ez egy ismert probléma, és adtak új 
drivert, amivel mar nem fagy ki a cucc - annyira. 

V: nincs 

Forrás: NetAcademia Offtopic lista 


K: Mit tegyek? A főnököm azt mondta, addig nem mehetek ha- 
Za, amíg a mentés le nem fut. Egyelőre még csak két óra telt 
el, de valószínűnek tűnik, hogy további három évig nem mehe- 
tek haza. Ti mit tennétek az én helyemben? És ha valóban nem 
mehetek haza, mivel üssem el a hártalévő 955 napot? 
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CBTTTTTEG E 


Device: 












5 eg 


Media name: IMedia created 5/93/2001 at 10.36 AM 
Statuz 


[Backing up files rom dísk... 


Piogtess 


Elapsed Estimated remaining 


2hr., 17 min. [955 day.. 2 hi., 42 min. 


orolt Information StorelFirst Storage Groupt. 
Processedt Estímated; 


IE giztejE  z ta 
2.400.719.727. [261.620.943.449.431, 


Time 





Ptocessingi 


Files: 


Bytes 






o Egyes cégeknél Tera, sőt Peta, sőt Exabájtos tároló- 
rendszerek vannak. Ezek mentése bizony soká tart! 


V: Türelem! 
Forrás: NetAcademia Offtopic lista 


K: A gépem egészen furcsán viselkedik. Amikor megbokroso- 
dik, egyszerűen magától töröl mindent, amit ér. És ha már 
mindent kitörölt például egy wörd dokumentumból, akkor 
meg csönget. Mit tegyek? 

V: Vedd le azt a nehéz tárgyat a Backspace billentyűről, ami 
rajta van 

Forrás: NetAcademia Offtopic lista 


K: Baj van a wördömmel. El akartam menteni a munkámat, 
és bementem a fájl menübe. Kattintottam a Save ponton, és 
erre eltűnt. No sebaj, gondoltam, majd a Save As elmenti ne- 
kem. Katt, és az is eltűnt. Most bármelyik menüpontra kat- 
tintok, az eltűnik. Gyors segítség kéne, mert már alig van me- 
nüpontom! Jaj, mit tegyek?? 

V: Sikerült belemásznod a wörd testreszabási lehetőségeinek 
legveszélyesebbjébe: a menütörlésbe. Ide úgy szoktak embe- 
rek betévedni, hogy egy spirálfüzetet ráejtenek a billentyű- 
Zzetre. Ekkor jó eséllyel egyszerre lenyomódik a CTRL, az ALT 
és a mínuszjel, s a kurzor is átalakul egy bazinagy mínusszá. 
Amire ezután kattintasz, az eltűnik. Lehet próbálkozni! 


E TS EN ZE ELEN át] 


] File Edit View Insert Format Tools Table Win 


1 D New. - Ctrl 

] E open... ctrlo 
dose 

Save Ctrl--S 


5 A File-2New... menüpont percei meg vannak számlál- 
va. Mindjárt lesújt az egér! 


Forrás: NetAcademia Offtopic lista 
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Systems Administrator 
( c1K 
4 
MCP - túl kevés? MCSE - túl sok(k)? Legyen MCSA! 


Az MCSA címre pályázóknak három kötelező és egy szabadon választott vizsgán kell megfelelniük. Bizonyítaniuk kell tudásukat a 
Windows 2000 Professional (070-210), a Windows 2000 Server (070-215) valamint a Windows 2000 környezet adminisztrálása terüle- 


tén (070- 218) valamint egy ja SOMICS témakörben. 


N VI CI Fi Tr 7 j f 
ÍVI I Más f.§ SZÁMALK Továbbképző 2002: év elejétől [gpetátis összóállítású . 
Microsoft rendszeradminisztrátori képzést indít, mely az alábbi tanfolyamokra épül: 












A kötelező vizsgákhoz: 
" 2151, 2152 - Implementing Microsoft Windows 2000 Professional and Server (üzemeltetési ismeretek, kie- 
gészítve az alapvető hálózatos és Active Directory részekkel a 2151-es tanfolyam tematikájából) 
s 2126 - Managing Microsoft Windows 2000 Network Environment (a Windows 2000 rendszer üzemeltetése) 


A tanfolyamokat különböző csomagokban kínáljuk: 


Standard csomag: 215142152, 2126 tanfolyam, ajándék táska: 220.000 Ft/fő 
Professional csomag: 2151-42152, 2126 tanfolyam, ajándék táska, plusz magyar nyelvű Kis Balázs könyvek (Windows 2000 Prof., 
Win. 2000 Server, magyar nyelvű 070-215 Readiness Review vizsgafelkészítő könyv, több mint 20.000 Ft értékben): 230.000 Ft/fő 
Premium csomag: 215142152, 2126 tanfolyam, ajándék táska, plusz a teljes Microsoft Press Windows 2000 Core Reguirements tré- 
ning kit (Win. 2000 Prof., Server, Network, Active Directory, CD-melléklettel, melynek értéke több mint 60.000 Ft): " 259.000 Ft/fő 


Meghirdetett időpontok tavaszra: 2002. január 28 - február 1., február 25 - március 1., március 4-8., március 25-29. 
A tanfolyamok vidéki helyszíneinken is elérhetők lesznek. Kérjük tekintse meg weboldalunkat. 


Az egy további szabadon választható vizsgához az alábbi tanfolyamainkat ajánljuk: 
" 2153 - Implementing Microsoft Windows 2000 Network Infrastructure (hálózatüzemeltetés) 
s 2159 - Implementing and Administering ISA Server 2000 (ISA Server 2000 üzemeltetés) 
s 2072 - Administering Microsoft SOL Server 2000 Databases (SOL adatbázis adminisztráció) 
Az MCSA képzésen résztvevő hallgatóink ezen tanfolyamok díjából további kedvezményt kapnak. 


xxukciók, cégeknek Pap 
tn 
077 
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